(6)—总结

1、实体应该要简单，层次最好平面化，这样有利于实体在各种通信中穿越(比如Webservices,WCF,Remoting,WCF RIA等); 2、虽然实体应该平面化，但并不代表不能有继承层次，因为这种层次可以获得很多管理和架构的好处 但要注意两点：       1是尽量采用接口，而且接口的方法或属性主要目的是提供统一访问实体的标准接口       2是属性的代码不要复杂，不要对外依赖，而方法更应该如此，能在操作类或者其它辅助类完成的尽量不要安排在实体类完成。     在整个架构体系中，实体类和系统定义的枚举等常量一样，应该处于引用的最底层，也就是实体类库原则上不引用你自己      定义的其它类库（当然，如果你把系统的常量定义，枚举定义等系统规范性定义放在一个类库，实体类库还是可以引用）。 3、采用根据实体（包括配置文件）动态构造SQL的方式与数据库交互，虽然大量的减少了数据访问和转换类，但也失去了很多灵活性，      如果关系数据库处理更加专业，那还是留给关系数据库去处理。 4、无论什么框架，数据从界面到数据库，该干的事情一件不能少，只是方式不同而已      实体框架提供的数据库访问功能，大部分都可以利用AutoCode工具自动生成，至于缓存，很多时候还是需要你自己去维护一部分。 5、成本的减少不是靠一个框架能解决，如果选择不当，反而会增加成本。      包括实体框架的学习成本，跟随成本，一些问题不太好解决的时候，曲线救国的成本等。 6、虽然没必要从汇编开始做起，但在可选的范围内，尽量使用较为原始的方式处理会根据持久性。      这主要是针对实体框架的劣势而言。 7、造船与租船：对于个人选哪个都可以，但对于国家则需要鼓励造船而不是租船。对于企业，在中国目前的氛围下，不做讨论。 8、项目管理者根据需要造或租，但作为程序员，还是多知道点造的技术为好； 9、虽然做技术不一定赚钱，赚钱不一定要技术，但做程序员还是要关注点技术，因为这至少暂时是你工作的需要。 整体上来讲，如果是项目的规模不是很大，可预见的业务关系不是很复杂，而且公司也不打算走产品路线，那么采用成熟的实体框架 应该是优先的选择；如果是个人搞一些系统，那当然是“拿来主义”至上。 在选择实体框架产品的时候，就我个人的观点，最好不要用微软的东西，虽然强大，但夹带的私货太多。 后记：在一个几乎人人都想一夜暴富的国度，谈技术都有些不合时宜....但惩罚却要开始了... 用市场没有换来值钱的技术，却换来了一堆连厕纸都不如的国债...道指暴泄，杯具的却是我们这些屁民, 奈何？