芝麻开门——遇见钱钱

By admin in bet体育在线网址手机版 on 2019年1月12日

自己在CSDN发布了一个帖子,披露一款强大的ORM工具–PDF.NET集成开发工具
,有个朋友caozhy提议了特别尖锐的题目,我对他的问题做了答疑,现在认为她的题材很有深度和代表性,现在整治在此处供大家钻探。

二零一八年第二本读书笔记

================caozhy的题目是========================:

《小狗钱钱》是德意志联邦共和国国学家博多.舍费尔写给孩子们认识财富,创设财富的钱财童话。共有两本,从物质和旺盛两规模指点子女们建立科学的传统、世界观、金钱观。作者将长远的道理蕴含在故事里面,通过12岁女孩吉娅和小狗钱钱一多重奇遇,将理财的学识通俗的讲给我们。虽说是写给孩子们的,可是对于理财小白来说,也足以改为入门书。

从技术的角度看,lz的想法是好的。

首先本书侧重教给子女怎么取拿到财富,管理财富。笔者通过故事告诉大家要想赢得财富,首先要问自己:“为啥想要变得富有?拿到金钱对于大家的含义何在?”唯有找到了金钱的意义,大家才能设置明显的目的。记得儿时听过一句“金钱是万恶之源”,也不知怎么,在投机不领悟的无心里,总认为有钱会招致不幸?可事实并非如此,金钱的我是中性的,并无好坏之分,首要看我们赋予它如何的含义。就如一把宝剑,可能割破你的手指,但也足以当做自卫的工具。追寻意义是做任何事的源流,意义可以给予方向,也帮大家建立目的。

可是从商业的角度看,存在部分题材:

这里作者介绍了一种办法,两个工具。方法是先写十个意思,并把十个心愿举行筛选,最后留给多个意思,这多个意思就足以转正为我们显著的对象。结合目的,推荐五个工具“梦想相册”和“梦想储蓄罐”。

(1)开发者能无法赢得技术匡助的担保?培训谁来做?
(2)后继的保养什么人来做?BUG修复?
(3)ORM的框架众多,lz的出品优势在什么地方?定位简单依旧功用强大?假设是简简单单,lz的那套语法/函数依然略显复杂。
(4)对于一款面向.NET的ORM框架,要是不兼容 IQueryable
接口是一种分外大的遗憾。这意味着,我还非得使用面向数据库架构的语法来支配业务逻辑。
(5)协理广大数据库虽然很好,不过lz怎样处理数据库方言问题?对于大多数低端用户来说,能很好很便利地处理好MSSQL就很正确了。对高端用户来说,帮助多数据库并不是绝无仅有的内需,他们需要安静、高效以及高伸缩性和可扩充性。说到底,仍旧定位问题。近期的Entity框架就做轻量,它不管和IDE的重组,依然ORM以及和语言的三结合,做的都很好。比如ModelFirst、CodeFirst或者按照表建模,而lz的方案看上去需要在数据库和模型代码之间定义一回,而且尚未很好将数据库架构和模型分离。
(6)ORM本身的纷繁没有用过的人很难想象。lz因为既是使用者,又是开发者,所以有考虑一直——如若我100%是以此框架的编者,或者自己对框架的拥有实现完全理解,我居然会考虑采用自己的框架代替通用的ORM。不过,倘诺我不是框架的设计者,没有读书过所有源代码(尽管你提供代码,我有没有力量去读依旧个问题),那么你假想的“轻量”、“简单”都是不设有的。简单的事物不是相对意义上的简便,而是可以尽量借鉴现有的学问以及对它的报告有充裕的把握。
(7)有没有可以说服我使用它可能并不是一个简短的例子,查询几条记下,事实上比较所有同类产品,实现这样的功效都很容易。我说几条EF的题目,不驾驭您的产品能否解决:
 – 对于泛型实体的支撑,倘使自己要设计一个考试系统:

干什么要有愿意相册啊?作者通过小狗钱钱回答:“人们把这种表现称作视觉化,成功的人就此成功,就是因为他俩一向希望着温馨成功的那一天。”比如您挣钱的目标是去亚洲旅行,这你就找一些南美洲美景图,每一天看看,加深我们对落实梦想的意思。愿望会让我们在白蒙蒙的时候,打败困难,突破一切障碍。

C# code
class Questions where T : QuestionBase { }
{
public List Questions { get; set; }
}
class QuestionBase { }
class SingleSelectionQuestin : QuestionBase
{
public string Description { get; set; }
public List Options { get; set; }
public string Selected { get; set; }
}
class MultiSelectionQuestin : QuestionBase
{
public string Description { get; set; }
public List Options { get; set; }
public List Selected { get; set; }
}
class BriefAnswerQuestin : QuestionBase
{
public string Description { get; set; }
public string Answer { get; set; }
}

稻盛和夫在《活法》里面写“想要做成某一件事,大家率先要把它描画成精美图景,然后再把贯彻它的经过,在脑力里模拟演练,直到看见它的结果得了。只要考虑到达每一个细节,目的就决然能兑现。”

Stephen柯维也说:“任何事情都是一遍创设而成的,大家做其他事都是先再头脑中构思,这是率先次成立,然后付诸实践,这是第二次成立。”

这种情况下,使用近来版本的Entity框架,我必须迁就数据库的筹划,这就是当前ORM缺陷的原委。

瞩望储蓄罐是攒钱方法,简单的说拿一个罐子写上团结的企盼,把它当作一个储蓄罐,将节约的钱都放进储蓄罐里。每一天为希望而拼命的感到,会让您的性命更加从容。

  • 对此多实例可扩大性的支撑
    诸如我的数据库部署到 SQL Server Azure 上,我的先后托管在Windows Azure

    WebRole里面。可能我有10个WebRole,并发访问数据库,数据一致性怎么确保?

    非凡复杂的数据库关系和架构,比如三个外键,级联查询,唯一性约束,参照完整性约束。比如自定义函数和SQL类型等等

    数据迁移问题,说实话,数据迁移是几乎所有人都关注的为主问题,而且是衡量ORM好坏的显要标准。对于一个渐进添加功用的Web程序,程序的进步,同时确保原有的数目平滑地迁移到新的数据库里面是特别紧要的事务。对于Rails的ActiveRecord,就做的很好。迁移几乎自动进行,甚至仍可以反向的动迁。
    在闭源产品(我是说.NET)上付出,这条路很惨淡,很多很大的产品相继倒下了,lz要慎重。

在谈到咋样致富?笔者说自信是盈利的基础,写成功日记,就是升级自信的特级艺术。要求每日坚定不移写五件成功的事。

 

盈利的思路从啥地方来吧?首先帮助别人釜底抽薪问题,就足以挣到钱。其次把肥力集中在自己精晓的、能做的和装有的东西上。再度最好用自己的趣味去赚钱。最后每一天不间断的去做对前途有意义的事情。比如您喜爱创作,即使暂时你并不可以靠她糊口,但您要么要咬牙去做这件事情,在作文时候考虑怎么样分享有价值,帮忙到外人的信息,将来有那么一天量变会时有暴发质变。

===============我的对答==========================:

一经你陷入了债务危机,作者给了六个忠告:一是毁掉信用卡;二是下跌分期付款额度;三是扣除生活费后一半钱要存起来,不申请消费贷款;四是购物时要问自己,这着实有必不可少吗?

分外感谢 caozhy 的提出和题材,下边逐一回应如下:
(1)开发者能无法博取技术匡助的管教?培训什么人来做?
–对于业内用户(也就是花10块钱购买源码的用户)提供在线襄助,培训资料在社区有连锁的博客、论坛小说;
(2)后继的护卫什么人来做?BUG修复?
–由于PDF.NET框架是在事实上商业产品中的应用,所以珍视从来在展开,效能扩张和Bug修复一贯在展开中;
(3)ORM的框架众多,lz的成品优势在哪儿?定位简单依旧效率强大?假倘使简简单单,lz的这套语法/函数如故略显复杂。
–框架的最紧要特征是有所iBatis的SQL-MAP功效和匡助.NET
2.0的面向对象形式的查询表明式OQL,定位是简简单单易用,在行使
SQL-MAP的时候,只需要写好SQL语句,有代码工具自动生成DAL代码;在应用OQL的时候,大部分都是单表简单的CRUD操作(
复杂的SQL语句都用SQL-MAP实现了),OQL.From(entity).Select(entity.Property,…).Where(entity.Property)
这样的语法依旧很简短的,
很接近SQL的写法,固然有相比较复杂的准绳,可能表明式构造稍显得复杂(但复杂的SQL都用SQL-MAP去实现了),Update、Insert、Delete操作
最简易,不用多说了;
(4)对于一款面向.NET的ORM框架,假使不般配
IQueryable
接口是一种分外大的缺憾。这代表,我还必须采取面向数据库架构的语法来支配业务逻辑。
–由于历史原因,框架最初定位在扶助.NET2.0,IQueryable 是.NET
3.0过后才支撑,目前正在考虑框架直接扶助LINQ;
(5)补助广大数据库尽管很好,不过lz咋样处理数据库方言问题?对于大部分低端用户来说,能很好很方便地拍卖好MSSQL就很不利了。
–正因为有例外数据库的白话问题,所以框架使用SQL-MAP技术,将这多少个需要迅速执行的、数据库特性的SQL单独写到配置文件中,当需要切换数据库的时候,
只是替换这些SQL配置文件即可(SQL-MAP配置文件);
“比如ModelFirst、CodeFirst或者依照表建模…”
–框架提供了从数据库来生成实体类的工具,但也允许你先ModelFirst、CodeFirst,我的广大演示(比如示例操作OQL的一对)都是直接创制实体类,
从没设计数据表的,假若采纳手工模式,你可以自定义要持久化哪些属性以及怎样持久化;
(6)ORM本身的扑朔迷离没有用过的人很难想象…可是,要是我不是框架的设计者…那么你假想的“轻量”、“简单”都是不设有的。
不太认同你说的“不是设计者”就不可以肯定框架是“轻量、简单”的这一个观点,“轻量”可以从软件的文件大小、对环境、系统的借助程度等方面来认定;
“简单”可以从骨子里使用过程体会出来,已经有好多用过仍然看过框架的爱侣一定的说“确实简单”了,例如参看这篇著作的东山再起:
http://www.cnblogs.com/bluedoctor/archive/2011/04/01/2001887.html

怎么着保管财富?

不选取反射的实体类方案
http://www.cnblogs.com/bluedoctor/archive/2010/02/08/1665795.html

作者讲了《鹅和金蛋》的寓言故事。以前,有个青春的农夫,每一日从鹅笼里捡一个鹅蛋当早饭。有一天,他甚至在鹅笼里发现了一个金蛋,至极如沐春风。第二天,如故有金蛋,这样的状态后续了几许天,可是农夫是一个利欲熏心的人,他对鹅非凡不顺心,为啥只有一个啊?每一天最少应当下五个金蛋,现在这样的进度太慢了,他怒火越来越大,末了他毕竟怒不可止的把鹅劈成两半,从这以后,他再也得不到金蛋了。

7)有没有可以说服自己动用它恐怕并不是一个粗略的例子…
–首先,框架不是个体闭门造车的产物,而是实实在在的体系拔取的结果,比如近来大家做的银行资本分析体系,这样的体系错综复杂和数据量自然不用怀疑的;
对此你的“对于泛型实体的协理”的题材,我想不是在泛型类本身协理实体的题目,而是QuestionBase具体贯彻类如何支撑实体类的问题,你能够先CodeFirst,
先规划“领域模型”(我以为你给的例子不再是一个简便的实体类了,而是一个世界模型),再手工对实体类举办持久化,例如持久化SingleSelectionQuestin:

鹅代表金钱,假设你存钱就会拿走利息,利息相当于金蛋。之所以说,每当我们有一笔收入的时候,大家要想方法喂养自己的鹅,唯有鹅的正常化才能确保金钱源源不断的面世。《高功效人士的七种习惯》里面也涉及这一个故事,把鹅比作产能,金蛋比作产出,产能与出新平衡,我们才有高功用的活着。

首先,指出你将 QuestionBase 定义为接口,

投资的三尺度是怎么啊?率先,应该把钱入股在平安的地点。第二,让钱下洋洋“金蛋”。第三,投资应该简单明了,易于操作。资产是一个正确的投资采用。在挑选资金时,有六个注意事项:一是资本应该至少有十年历史;二是相应拔取大型的跨国股票基金;三是对资本的增势图进行比较,我们应有寓目过去十年间如何成本的年底净利润最好。

C# code

其次本书侧重告诉儿女们在得到财富的同时,必须具备的情操。首要讲了一个驳斥,七条轨道。

interface QuestionBase
{
  public ID{get;set;}
}

“甜甜圈理论”是指金钱就像甜甜圈外这么些看得见的圆形,而甜甜圈内部无形的圆孔则代表人的内心,象征着大家无能为力看出却又无法不具有的品德,这是比看得见的功成名就更要紧的东西。阿姨娘吉娅质疑道:“那一个圆孔根本什么都不是啊,他可是是空空的而已!”圆孔确实是空的,当你掉进洞里的时候,才会感受到这一个口,是属实存在的。

接下来,修改单选实体类:

本条理论,让自己记念《道德经》中“故有之,以为利,无之以为用。”

C# code

老子也说,一般人只在意有所的事物及其功用,而忽视了纸上谈兵的东西及其职能,“有”和“无”是相互依存,互相为用的,无形的东西能生出很大的成效,只是不易于被人所发现。比如房子,墙壁是负有的,大家无法住在墙头上吧,容纳我们的反是墙与墙组合的空间中。

class SingleSelectionQuestin : QuestionBase,EntityBase
{
    public string Description { 
    get{return getProperty<string>("Description");} 
    set{getProperty<string>("Description",value,50);}//假设Description 字段长度为50
    }

    public string Tb_Options { 
    get{return getProperty<string>("OptionList");} 
    private set{getProperty<string>("OptionList",value,500);}//假设OptionList 字段长度为500
    }

    public List<string> Options { //假设Options 的结果以逗号分隔的字符串的形式,存在与数据库表字段OptionList 中
    get{this.Tb_Options.split(',').ToList();} 
    set{this.Tb_Options= string.join(value.ToArray(),",");} 
    }

    public string Selected { 
    get{return getProperty<string>("Selected");} 
    set{getProperty<string>("Selected",value,50);}//假设Selected 字段长度为50
    }

    public int ID { 
    get{return getProperty<int>("ID");} 
    set{getProperty<int>("ID",value);}
    }


    public SingleSelectionQuestin()
    {
         TableName = "TB_SingleSelectionQuestin";//表名称

            //IdentityName = "标识字段名";
    IdentityName="ID";

            //PrimaryKeys.Add("主键字段名");
    PrimaryKeys.Add("ID");

    }

      protected override void SetFieldNames()
      {
           PropertyNames = new string[] { "ID","Description","Selected","OptionList"};
      }


}

何为普世真理?就是这一个纵横古今,横贯东西,经过实践验证的,被我们号称“大道理”的这一个话。好比《鹅和金蛋》的故事,在本国就用“杀鸡取卵”来告诫人们不要只看重长期利益,忽略了好久利益。

末段,在你需要的地方来取得QuestionBase类的实例,例如:

那么哪些是“无”呢?内在的风骨。要建立高尚的品格,作者又通过孩子们欣赏的铤而走险故事,给出了两个准则:“友好亲和,善待旁人,感恩之心,勇于承担,援助给予,勤学不辍,值得信任。”

C# code

初读这本书感觉有些像《苏菲的日记》,但易懂多了。读后鼓励同样12岁的幼女也看看,她用半个钟头就翻完第一本,说:“二姑,我怎么觉得离自己的生活很遥远?”从小大家被指点,作为孩子,努力学习就好,挣钱理财是父阿姨的事。看完本书,引发一体系思考,鼓励子女读书是干什么?无非是跻身好的大学。为啥上好的高校?是为着有好的办事。人生来目标是为了有一份好的劳作约束自己呢?当然不是,是为了对生存通晓更多的主动权,有更多的随机,更大的进步空间。而达成那么些目的,首要条件是财物自由。所以,给男女灌输理财意识不是以后的事,而在当下。当下相仿无用的东西,将来必将会有大用。

QuestionBase question= QuestionFactory.GetQuestionInstance();//假设有这一个问题类工厂
 question.ID=100;//给问题ID赋值
 EntityBase entity=question as EntityBase;//实体类基类
 EntityQuery<EntityBase>.Fill(entity);//填充该实体
 //下面对实体类进行其它操作
 EntityQuery<EntityBase>.Instance.Update(entity);//保存修改

这段代码可以放置你需要的地点;

拔取这种CodeFirst的方法,最后依照需要来持久化实体类,就不需要迁就数据库表的统筹了。

(8)- 对于多实例可扩充性的支撑
–并发访问数据库,数据一致性的要求,对于ORM来说是不是讲求太高了些?这多少个本该是数据库或者特其余事务层去做的事情;
(9)-
十分复杂的数据库关系和架构,比如四个外键,级联查询,唯一性约束,参照完整性约束。比如自定义函数和SQL类型等等
–PDF.NET的实体类本着从简的规则,实体类没有引入复杂关系的定义,境遇那一个纷繁的询问,能够采纳SQL-MAP效用,它可以将DataReader的结果读入实体类中;
(10)-
数据迁移问题,说实话,数据迁移是几乎所有人都关心的核心问题,而且是衡量ORM好坏的根本标准。
–下边这一个现象是否与你的这几个题目类似?
咱俩有一个序列,有部分基础数据需要从我们的SQLSERVER库远程同步到客户的体系中,而客户的系统运用的数据库最近有SQLSERVER,PostgreSQL,这样的数码同步
算不算类似你说的多少迁移呢?请参见我上边的稿子:
唯一不变的就是平素在变”–“数据”的豪华“变身术” 
http://www.cnblogs.com/bluedoctor/archive/2011/02/23/1962218.html

在系统的兑现中,有关数据的导入和导出,选择实体类很好的遮光了数据的距离,比如目的表和源表字段名称和数量不均等的题材。

注:有关PDF.NET数据访问框架的问题,请参考官网地址

http://www.pwmis.com/sqlmap

或者自己的博客相关随笔。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图
Copyright @ 2010-2019 mobile.365-838.com 版权所有