======== 关于字段映射 类调用 数据读取逻辑============

[愚者只看星不看答案]

假设当前有一个用户表有以下字段
ID
UserName
Email
ZipCode
Address
PhoneNumber

有一个用户实体类，和上面的表字段完全对应。

现在让你开发一个类库,其中包含以下方法

一个用于读取用户表中的所有用户集合的方法 GetAllUsers,返回 用户实体类 的集合
一个读取指定用户的 GetUserById 方法,返回一个 用户实体类

现在有以下不同的若干页面
A页面，仅仅显示 ID UserName
B页面，仅仅显示 ID UserName Email
C页面，仅仅显示 ID UserName PhoneNumber

因为你在开发类库让别人调用，所以你无法知道别人会不会使用 PhoneNumber 这个字段,所以你在类中的每个方法中都查询出了 PhoneNumber 这个字段,但是如果从业务需求的层面来看，A,B页面并没有使用到 PhoneNumber, 返回这个字段对于 A,B页面并没有意义，尤其是在表数据量大的情况下，浪费带宽及其它资源 。
这个问题，你们是怎么处理的?

如果为了避免这种浪费，你创建了以下方法
GetAllUsers_For_PageA ,返回 用户实体类 的集合,除 ID UserName 以外，其实属性值都为null

GetAllUsers_For_PageB,,返回 用户实体类 的集合,除 ID UserName Email 以外，其实属性值都为null

GetAllUsers_For_PageC,,返回 用户实体类 的集合,除 ID UserName Email PhoneNumber以外，其实属性值都为null

这样最大程度上节省了资源，但是返回的是相同的 用户实体类，在
GetAllUsers_For_PageA 的情况下 Email 为 null 值
在
GetAllUsers_For_PageB的情况下 Email 不为null值

在这种情况下，你又如何在文档中解释 用户实体类 的 Email 属性在什么情况下是 null ,什么情况下是非 null ,这个同样很奇怪..

请问大家，你们平时怎么处理此类情况?多谢

一直很困惑这样的问题，请大家耐心指教。。

[愚者只看星不看答案]

引用 8 楼 wanghui0380 的回复:

你要知道早期的VB,delphi的数据模块 中期的dal 通通都有一样的毛病，比如一个dal，我见过8千个方法。 getxxxByAaaa getxxxByAaaaAndBbbb, 后面的人连名字都起不了，因为被人起光了，嘿嘿，直接写 getxxxx某某界面专用

完全完全同意，特别有感触。。现在的数据访问层到处都是 GetxxByxx ,太多了，所以我就认为要重新思考 这样的方法了，不能为了开发模式而讲究开发模式。。。

[娃都会打酱油了]

业务层返回业务dto，包含你认为该返回的所有数据，然后你的问题是view层向外抛出的vo，dto和vo转换的过程本来就应该存在的，除非你们对vo的要求并不严格 这个vo一般来说就是mvc展示层里面的Models

[stherix]

你要这么做也可以 不过你可以对不同的页面返回不同的接口,比如A页面获得的是IUserName,B页面的是IUserNameEmail,虽然都是User对象 要么就创建多个不同的实体类

[愚者只看星不看答案]

引用 2 楼 stherix 的回复:

你要这么做也可以 不过你可以对不同的页面返回不同的接口,比如A页面获得的是IUserName,B页面的是IUserNameEmail,虽然都是User对象 要么就创建多个不同的实体类

是的，是的。。我也考虑过，创建一个只有 Id,UserName 的基类，然后再继承出一个带有 Email的，太这样也太累了。。。 你们平时怎么处理此类问题的,多谢

[stherix]

引用 3 楼 愚者只看星不看答案 的回复:

[quote=引用 2 楼 stherix 的回复:] 你要这么做也可以 不过你可以对不同的页面返回不同的接口,比如A页面获得的是IUserName,B页面的是IUserNameEmail,虽然都是User对象 要么就创建多个不同的实体类

是的，是的。。我也考虑过，创建一个只有 Id,UserName 的基类，然后再继承出一个带有 Email的，太这样也太累了。。。 你们平时怎么处理此类问题的,多谢[/quote] 我是说可以只要一个实体类,但是有多个不同的接口,接口有各自需要的属性对应不同的页面

[智者知已应修善业]

楼上说得对,实现不同接口即可

[OrdinaryCoder]

static List<T> GetAllUsers<T>(T mdoel)
        {
            //获取该类所公共属性
            PropertyInfo[] properties = mdoel.GetType().GetProperties();
            // 遍历
            foreach (var item in properties)
            {
                //获取字段名
                string name = item.Name;

                Console.WriteLine(name);
            }
            return null;
        }

是不是可以这样封装一个泛型接口 根据传入的类型来确定返回集合的类型

[wanghui0380]

个人表示，当仓储碰上这个就是问题 但是如果你不仓储，你天生是 IQueryable<T>呢，还有问题么？ 你说的很对，你无法预知别人要什么，用什么过滤。所以我们把选择权交出去，他自己决定自己要什么。 当然一旦到具体的服务边界上，这个就是具象了，这个服务边界他自己知道要提供什么服务，要给多大颗粒度。 所以作为底层，我们不跟仓储那波人一样过度修饰，简简单单的，干干净净就好。 我们只在服务边界去根据服务场景细节化

[wanghui0380]

你要知道早期的VB,delphi的数据模块 中期的dal 通通都有一样的毛病，比如一个dal，我见过8千个方法。 getxxxByAaaa getxxxByAaaaAndBbbb, 后面的人连名字都起不了，因为被人起光了，嘿嘿，直接写 getxxxx某某界面专用

[wanghui0380]

也就是如上面的人说的，VO是VO，作为底层供应，我们不管vo 你自己说，这是pageA，这是pageB，其实有pageA，pageB的不同，那是做页面的人自己要求的，所以其实没有什么文档，这个具体服务提供，是你页面要求的，我无需写文档解释什么。相反你做页面的反而要跟我写文档，说明为啥这样要，原来有啥问题，为啥要独立提供。你不提要求，我就先提供统一的，直到你提出“我是特殊的，给我独立供应”