关于实体类的问题 PetShop中的业务实体类联系了数据库与面向对象程序,是个不错的载体。但如果某个数据表字段类型发生了变化,或者增加、减少了某个字段,那么想必就得需要修改业务实体类,这样岂不是不灵活?还是有其它的解决方法?请高手赐教。 解决方案 » 免费领取超大流量手机卡,每月29元包185G流量+100分钟通话, 中国电信官方发货 这个问题讲过N遍了,从面向对象设计的角度,PetShop没有重用价值,所有ORM和基于ORM相同观点的都认为数据库和代码直接存在着映射关系,这个出发点本身就违反了SOLID设计原则实际上,同一个版本的应用程序完全可以挂接数据结构并不相同的不同的数据库 很多号称业务实体的代码只不过是数据结构的克隆,能把业务逻辑和数据结构眉毛胡子一把抓弄在一起的就算不错了,更多的是把CURD抄2遍,一遍号称DAL,一遍号称BLL 如果我说PetShop并算很好,而同样是MS小组的另一个范例Domain Oriented N-Layered则好了许多,你信吗?Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App 实体是BLL层给表现层暴露出来的数据类型,它的更重要的作用是构成编程接口,它体现的是业务理解。比如说我们在应用程序中为用户绘制“山川、河流、建筑物、矿产、设备”的图形,这些东西在数据库中都是一些来源于其它系统(例如来自于遥感航拍的记录文件、商业卫星数据服务等等)的数据,可能有几十种,应用程序就是负责把它们展现的。这里的实体就是这应用中所用到的数据概念,例如领导说“我要看一下建筑物和设备这两层的分布情况”,没有一个领导会拿一堆最终数据的格式的术语去说业务概念。也就是说,真正地设计实用的系统,你肯定会从实用出发,去花精力去设计实体。此时不纠缠于底层数据库表,而只是运用一些关于底层已经现成的成熟系统的基本知识和经验。如果你只是把数据库表当作实体,那么你的表现层大概除了千篇一律地对最低级数据的“增删改查”界面拼凑几个,也就想不出更有创意的产品设计思路了。那么你所在的公司也就不会有拳头产品。就算是“增删改查”这种层次的OA比较容易开发,可是天长日久,成本也是高昂的。那么还不如提高设计层次,从实际千变万化的应用角度去划分实体类型,做到设计思想与底层实现的真正分离。 it's a balance problem. 很多号称理解三层架构的同学,都是把Linq、SQL写到表现层,用了个接口就以为是面向对象设计,无语...... http://blog.csdn.net/liuxiaodong_blog/article/details/2809024 请问,怎样获取下一个网页的地址 JS匿名函数 如何在一个文件中连续写入数据 这段程序用C#.net该怎么写呢? ImageButton的onclick为什么不能调用脚本函数 请教各位!C#中SQL语句的优化。 求代码,asp下登陆问题的 有关连接SQL 2000打包后的问题 如何在treeView 中动态添加子节点? 请问在C#中,怎样计算一个汉字的区位码? 请各位有大虾来帮我解答写这样一个问题(QQ,即时通讯类)谢谢 序列化和反序列化XML的问题
从面向对象设计的角度,PetShop没有重用价值,所有ORM和基于ORM相同观点的都认为数据库和代码直接存在着映射关系,
这个出发点本身就违反了SOLID设计原则实际上,同一个版本的应用程序完全可以挂接数据结构并不相同的不同的数据库
能把业务逻辑和数据结构眉毛胡子一把抓弄在一起的就算不错了,
更多的是把CURD抄2遍,一遍号称DAL,一遍号称BLL