多表查询的实体类怎么设计?

[ayun00]

在传统的三层架构中 , 一般entity层的属性字段都和数据库字段一致(至少我接触的是这样) ,如果有父子关系 就多一个 list

但是现在的业务经常要多表查询 , 每次查询需要的字段都不一样 ,
这样需要在entity层中 在单独写一个 entity类 来对应这次的查询吗, 然后每次手工去给每个字段赋值?(ps:如果是和数据库一一对应的话, 有很多代码生成工具能用)

请问大神们是怎么解决的?
1.老老实实的写实体类 ,然后写对应的 属性赋值类?(想想 , 那么多属性要去手工写代码, 还要担心敲错字母, 就感觉恐怖 )
2. 丢一个 datarow给 业务层, 让业务层去 创建一个 匿名类? (不能用强类型的提示, 好悲伤...)

[ayun00]

引用 1 楼 feiyun_Web 的回复:

EF生成的时候如果有用到“关系”的话，会生成一个集合属性。 如果是自己写一个DLL，那就老老实实的填充。 建议使用数据转实体，然后将对象赋值到这个属性。

对每个业务都创建一个实体类?

[我是飞云]

引用 2 楼 ayun00 的回复:

[quote=引用 1 楼 feiyun_Web 的回复:] EF生成的时候如果有用到“关系”的话，会生成一个集合属性。 如果是自己写一个DLL，那就老老实实的填充。 建议使用数据转实体，然后将对象赋值到这个属性。

对每个业务都创建一个实体类?[/quote] 应该说每个表创建一个实体，然后将可能的关系表带入。比如说下面这个类

    public partial class UF_Admin
    {
        /// <summary>
        /// 管理员ID
        /// </summary>
        public int ID { get; set; }

        /// <summary>
        /// 管理者帐号
        /// </summary>
        [Required]
        [StringLength(30)]
        public string Username { get; set; }

        /// <summary>
        /// 管理员角色
        /// </summary>
        public IList<int> RolesList { get; set; }

        /// <summary>
        /// 管理员的权限代码
        /// </summary>
        public IList<string> OperateCodeList { get; set; }

[以专业开发人员为伍]

三层结构，其 Model 的设计当然是首先从前端应用需求出发的，而不是从什么数据库表出发的。在业务逻辑层，它将 Model 中的数据通过 DAL api 方法写入数据库、或者查询数据库，它自然就有一个转换。 假设你的 DAL 方法，或者上述 BLL 方法，是将某个与数据库表对应的 Model（或者其集合）写入数据库，这并不代表着 BLL 面对表现层的 Model 就只能纠结于数据库表。 相反地，满脑子只有“增删改查”的人缺乏表现层设计创意，一遇到千奇百怪的 UI 变化需求就怂了，就不知道如何设计“三层”程序了。这就是因为理念错误造成的。

[以专业开发人员为伍]

如果你站在“发展”的角度看设计，你会看到 Model 总是不断翻新的。可能某一个 BLL 服务所输入输出的 Model，实际上在后台数据库里涉及到8个数据表，甚至涉及到多个系统的SOA架构，甚至有些根本就是内存里的缓存着的统计汇总表结果（因为重复查询相同条件的统计结果，所以缓存）而并不是数据库系统中的表。 假设一个比较复杂的、面对多种多样前端的企业业务系统有 400 个Model，那么数据表不过就只有180个表。业务用的 Model 的数量往往远大于数据库数据表的数量。这说明业务层比较成熟，可以处理各种扩大或者缩小范围的高性能前端访问，其反应的业务服务功能是面向前端需求的，而不是简单地面向“增删改查”的。

[以专业开发人员为伍]

思想意识上的问题，不要因为看似说起来非常简单就轻视它，它并不容易像某些代码或者流行的UI 框架那样去现学现卖。要接受一个思想意识上的改变并且全盘应用到自己的设计中，需要至少3年以上时间。但是你可以从理论来看明白，不同人对于“三层”概念的出发点，有着多么大的不同。完全是“一个天上一个地下”的两极的不同。

[ayun00]

引用 6 楼 sp1234 的回复:

思想意识上的问题，不要因为看似说起来非常简单就轻视它，它并不容易像某些代码或者流行的UI 框架那样去现学现卖。要接受一个思想意识上的改变并且全盘应用到自己的设计中，需要至少3年以上时间。但是你可以从理论来看明白，不同人对于“三层”概念的出发点，有着多么大的不同。完全是“一个天上一个地下”的两极的不同。

你的意思 换句话说 就是 codefrist?

[我是飞云]

EF生成的时候如果有用到“关系”的话，会生成一个集合属性。 如果是自己写一个DLL，那就老老实实的填充。 建议使用数据转实体，然后将对象赋值到这个属性。

[代码-小子]

[align=center]

[/align]