请教实体类的问题，请大牛们进来指教下，谢~~~
一般目前在DAL层中,数据操作基本习惯如下模式(demo)
public IList<Model_Users> GetUsersModel(){
return IList<Model_Users>; //这里执行一个查询用户信息的sql，返回一个用户信息的实体
}
//用户信息的实体
public class Model_Users{
private int _id;
private string _name;
public int id{ get;set;}
public string name{get;set;}
}
但是，当Model_Users这个实体不能满足需求时，比如在DAL层查询时，查询用户信息的同时，关联查询到了此用户的角色之类的,于是这个实体又变为:
public class Model_Users{
private int _id;
private string _name;
private int _roleId;
private string roleName;
public int id{ get;set;}
public string name{get;set;}
public int roleId{get;set;}
public string roleName{get;set;}
}
这时候
public IList<Model_Users> GetUsersModel(){
return IList<Model_Users>; //这里的方法就不能通用了,因为Model_Users又增加了两项属性.
}
类似这些问题:当DAL的查询改变时，返回的数据集不同，对应的实体对象不能一一对应的问题请问大家是怎么解决的>?
当然，你可以说，直接返回一个DataSet或是DataTable不就得了，何必搞那么复杂...，不过，此方法不在本贴讨论范围.
因为若不是用MVC架构的，对应的接口层返回的对象必须和继承它的类同步,当大家碰到许多在改变了数据查询却又想使用实体类这种方式(模型)对数据进行处理时，除了不断手动增加实体类外。。。其他的方法不知道有哪些呢？
-----------------------------------------------------------------------------------------
这里好像涉及到了ORM模型的问题。不过在下看了下，实在看不出个所以然.请教大牛们如何做的?
还有就是，各位大牛们碰到此类问题的解决方案是如何的，请通俗地指教下，不胜感激! --------------------编程问答-------------------- 另外，补充个问题：
假设用利用发射将数据库查询数据动态生成实体类，性能上如何做到更好？ --------------------编程问答-------------------- 这个我觉得应该没什么问题啊，直接用底下属性比较多的那个实体类不久可以了，如果查到的关联表中没有角色的信息，实体类中的那个角色就让它为空，和你想做的事情应该不矛盾吧，空了也就相当于没有，如果查到了就赋值 --------------------编程问答--------------------
public IList<Model_Users> GetUsersModel(){
return IList<Model_Users>; //这里的方法就不能通用了,因为Model_Users又增加了两项属性.
}
//这里为什么不能用？你只是增加了属性而已，对于你这个类对象，还是一样的，
//如果需要返回增加的2项属性，需要手动去加上。
//返回的实体类是同一个，增加属性有影响吗？
//三层架构嘛，不管是业务层还是数据层，实体类都是同一个吧？
假设用利用发射将数据库查询数据动态生成实体类，性能上如何做到更好
这个可以加上缓存。 --------------------编程问答-------------------- 通常context上下文关联机制解决
在mvc中实际还有一派，叫MVVM派
既 model---View-----ViewModel的解决方案
有关这一派的东西：自己google把
http://www.google.com.hk/search?client=pub-5434506002917399&prog=aff&channel=2000052003&q=MVVM --------------------编程问答-------------------- 搞不懂楼主的意思，呵呵 --------------------编程问答--------------------
这里假设sql查询返回的不是角色，而是其他的关联查询，那我岂不是又要增加一个对应的实体了？原实体如(Model_User),这里没有相关的属性，我又加增加或是新建一个，这样干脆不用实体做为载体算了，这也是我问这个问题的初衷：如果在数据查询改变时，非手工修改或增加实体.不然的话，实体的存在反而成为没意义的了，因为数据集返回的结果与实体属性不一致。而后面看到一些关于ORM的介绍，不过，知识而太小，不是很懂，呵~~ --------------------编程问答--------------------
在目前的项目应用到的不是MVC架构的，是普通的三层，说实在的，对于MVC了解不是很多，惭愧。。。。 --------------------编程问答-------------------- 另外请区别一下，你的DAL
实际按你上面的例子，你的DAL里面的那个 实际并不叫 Model，那个东西应该叫DataModel
DataModel实际是按关系模型建立的，而Model是对象模型建立
关系模型 和 对象模型 不匹配这个在目前普遍使用的数据库下 几乎都是一定地
所以ORM不神圣，尤其是那些不区分 “关系”和“对象”区别的人来说，ORM被滥用了
--------------------编程问答--------------------
受教了~~谢谢指出。那这个DataModel有什么方法根据不同的查询对象改变成动态改变呢？ --------------------编程问答-------------------- 什么叫做实体？什么叫做DAL？我猜你的项目中没有BLL，因为你把BLL问题当作DAL问题来讨论。
你需要什么对象（类）？当你作为一个应用接口首先提供Model_Users(这里加个s可能太随意了）作为第一个BLL方法返回之后，又为第二个BLL方法打算增加两个字段，那么至少有三种可能的做法：
1. 扩展这个Model_User类，增加两个字段，并且重复以前所有测试，如果测试通过，说明增加这两个字段没有bug，因此完全可以增加这两个字段。
2. 设计新的类型，例如Model_UserAndRole:
public class Model_UserAndRole: Model_User
{
public int roleId{get;set;}
public string roleName{get;set;}
}
3. 返回一个描述它们的关联的类：
public class Model_UserAndRole
{
public Model_User User{get;set;}
public Model_Role{get;set;}
}
至于你说的“mvc架构”，最好不要把“asp.net mvc”随便简写为“mvc”，以免张冠李戴。 --------------------编程问答--------------------
感谢sp1234的指教，在这些方 面，在下是很菜的，许多不足之处麻烦指出下，占用各位大牛的一点宝贵时间，认真地向大牛们学习>
按上述做法，在原基类上派生一个新的基类(如sp1234所述的),纠正在下之前的一种叫法，在IList<Model_Users>里的Model_Users实指DataModel.
那么，或者接下来会有更复杂的需求:
如，DAL返回的是一个复杂的多表关联查询(还是基于Users表，即是Users的扩展属性),这时，又再次派生一个子类？
每当遇上这些问题就再派生出一个吗？不知道有没有更好的方式,就好像:
LIist<T> 这里的T实质上是变化的。简述为一个很通俗的问题:
各位在设计DAL层时,DataModel是如何设置的？即是说，当您查询的记录集里，当前项目中没有对应的DataModel没有对应，您是如何操作的？（基于三层结构，非MVC） --------------------编程问答-------------------- 假设微软做出点东西，它告诉你什么“实体类”是跟关系数据库表一一对应的，而你在表达查询结果对象集合时发觉无法表达，这是很正常的。因为你要是查询出来的东西不是按照BLL需求的对象结构来设计的，而反而自信矛盾地按照什么实体类的结构来设计查询结果，岂不是白白花钱死读书了嘛！ --------------------编程问答--------------------
那倒是我不懂变通了，呵呵~~谢谢~~不知道您是如何做的呢？对于此类问题？
--------------------编程问答-------------------- 有项目管理经验的.NET开发的朋友，可以加上限500人的QQ群28720769，一起交流。 --------------------编程问答--------------------
主要是习惯上使用obj.成员对数据进行处理的方式了。
有点思想固化的感觉,感觉到一但查询结果不一致时，又需要重复地去创建对应的DataModel,这样子感觉非常不合理，因为若查询结果可以说是变很多的，那么对应的DataModel岂不是一直要。。。呵呵~~不好意思，麻烦您了 --------------------编程问答-------------------- 首先，查询输出的是你的所有前台业务程序所见到的标准api中的对象类型，因此我不认为它是什么“实体”，我也对是否要八股文地必须追加一个Dataxxx前缀不感兴趣，关键地是这些东西都不是原始的实体，而是那些查询结果，它既可能把实体当作查询结果，也可能组装过的报告对象。
你问“每当遇上这些问题就在派生出一个吗”？你会遇上什么呢？我要问的问题是：你到底认为软件是为了业务人员所需要的前台界面应用而服务，还是软件设计是先搞一堆数据库表结构然后再八股文地套用一些“增删改查”的由程序员凭空胡乱写一些前台界面呢？
一个应用软件再设计时（既你说的“每当遇上这些问题时”），首先要看看BLL层api文档有没有相关的服务对象（类），如果有它就使用它们，而调整自己关于Model的想法；如果BLL设计没有支持业务逻辑，那么就可以建议BLL设计师创建一组新的、相关业务的接口以及更新其说明文档，直到逻辑上完全可以达到应用软件界面层的需求。
我没有说“是还是不是”派生出一个新类，这是协调和设计的产物，不然要pm和架构师还有什么用啊！ --------------------编程问答-------------------- 如果一个软件架构师关注前台应用，而不是整天玩后台数据库那一点东西，他就不会在什么时候该创建新的类型时有很多疑惑。很多东西都是先做出来，然后重构。反倒是整天发愁什么是“完美的”设计的人，似乎很少做实际的产品。 --------------------编程问答-------------------- 实际上你的问题其标题跟实际是表里不一的，我相信你的矛盾也在这里。我想跟你说的是，设计查询接口以及查询结果类型，根据前台应用程序业务、界面、交互操作的设计需求，而不是根据关系数据库表来设计。 --------------------编程问答-------------------- 谢谢~~晚上结贴~~~ --------------------编程问答-------------------- mark --------------------编程问答-------------------- 不明白 --------------------编程问答--------------------
路过,看了下!
补充：.NET技术 , ASP.NET
