关于实体类的有关问题
关于实体类的问题
PetShop中的业务实体类联系了数据库与面向对象程序，是个不错的载体。但如果某个数据表字段类型发生了变化，或者增加、减少了某个字段，那么想必就得需要修改业务实体类，这样岂不是不灵活？还是有其它的解决方法？请高手赐教。
------解决方案--------------------
这个问题讲过N遍了,
从面向对象设计的角度,PetShop没有重用价值,
所有ORM和基于ORM相同观点的都认为数据库和代码直接存在着映射关系,
这个出发点本身就违反了SOLID设计原则
实际上,同一个版本的应用程序完全可以挂接数据结构并不相同的不同的数据库
------解决方案--------------------
如果我说PetShop并算很好，而同样是MS小组的另一个范例Domain Oriented N-Layered则好了许多，你信吗？
Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App
------解决方案--------------------
实体是BLL层给表现层暴露出来的数据类型，它的更重要的作用是构成编程接口，它体现的是业务理解。
比如说我们在应用程序中为用户绘制“山川、河流、建筑物、矿产、设备”的图形，这些东西在数据库中都是一些来源于其它系统（例如来自于遥感航拍的记录文件、商业卫星数据服务等等）的数据，可能有几十种，应用程序就是负责把它们展现的。这里的实体就是这应用中所用到的数据概念，例如领导说“我要看一下建筑物和设备这两层的分布情况”，没有一个领导会拿一堆最终数据的格式的术语去说业务概念。
也就是说，真正地设计实用的系统，你肯定会从实用出发，去花精力去设计实体。此时不纠缠于底层数据库表，而只是运用一些关于底层已经现成的成熟系统的基本知识和经验。如果你只是把数据库表当作实体，那么你的表现层大概除了千篇一律地对最低级数据的“增删改查”界面拼凑几个，也就想不出更有创意的产品设计思路了。
那么你所在的公司也就不会有拳头产品。就算是“增删改查”这种层次的OA比较容易开发，可是天长日久，成本也是高昂的。那么还不如提高设计层次，从实际千变万化的应用角度去划分实体类型，做到设计思想与底层实现的真正分离。
PetShop中的业务实体类联系了数据库与面向对象程序，是个不错的载体。但如果某个数据表字段类型发生了变化，或者增加、减少了某个字段，那么想必就得需要修改业务实体类，这样岂不是不灵活？还是有其它的解决方法？请高手赐教。
------解决方案--------------------
这个问题讲过N遍了,
从面向对象设计的角度,PetShop没有重用价值,
所有ORM和基于ORM相同观点的都认为数据库和代码直接存在着映射关系,
这个出发点本身就违反了SOLID设计原则
实际上,同一个版本的应用程序完全可以挂接数据结构并不相同的不同的数据库
------解决方案--------------------
如果我说PetShop并算很好，而同样是MS小组的另一个范例Domain Oriented N-Layered则好了许多，你信吗？
Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App
------解决方案--------------------
实体是BLL层给表现层暴露出来的数据类型，它的更重要的作用是构成编程接口，它体现的是业务理解。
比如说我们在应用程序中为用户绘制“山川、河流、建筑物、矿产、设备”的图形，这些东西在数据库中都是一些来源于其它系统（例如来自于遥感航拍的记录文件、商业卫星数据服务等等）的数据，可能有几十种，应用程序就是负责把它们展现的。这里的实体就是这应用中所用到的数据概念，例如领导说“我要看一下建筑物和设备这两层的分布情况”，没有一个领导会拿一堆最终数据的格式的术语去说业务概念。
也就是说，真正地设计实用的系统，你肯定会从实用出发，去花精力去设计实体。此时不纠缠于底层数据库表，而只是运用一些关于底层已经现成的成熟系统的基本知识和经验。如果你只是把数据库表当作实体，那么你的表现层大概除了千篇一律地对最低级数据的“增删改查”界面拼凑几个，也就想不出更有创意的产品设计思路了。
那么你所在的公司也就不会有拳头产品。就算是“增删改查”这种层次的OA比较容易开发，可是天长日久，成本也是高昂的。那么还不如提高设计层次，从实际千变万化的应用角度去划分实体类型，做到设计思想与底层实现的真正分离。