数据模型类设计原则？碰到问题了请假大家！

Question

在下语文是体育老师教的，如若表达不清，请大家谅解。
直接举个例子吧！
比如说用户信息，由于用户的信息很多，于是按照业务需求分开存放：基本信息（Account）、联系信息（ContactInfo）、金融账户信息（FinanceInfo）（系统有充值交易的功能）等等。按上述划分成多个表来存储，这些表之间都是一对一的。并且创建了相应的数据模型类（Account、ContactInfo、FinanceInfo等等)。由于业务的需求，需要获取一个账户List，List中的Item不仅仅是Account，也可能包含ContactInfo或者FinanceInfo等等。请问这个情况下如何处理。
如果只需要获取Account，那就直接返回List<Account>；如果需要Account和FinanceInfo，可以返回ListKeyValuePair<Account,FinanceInfo>；如果需要三个或三个以上，这个方式就搞不定了。另外还有个办法，将其他的数据模型（ContactInfo、FinanceInfo）作为基本信息数据模型类Account的属性（字段），这样直接就返回List<Account>就可以了，但是这样有个弊端，每次获取Account的时候，都需要将ContactInfo和FinanceInfo读取出来，造成不必要的浪费。最后，我还想问一下，在实际操作中，出现这样的情况是不是设计的不合理？是不是最多应该只是需要获取基本信息Account+相应的业务信息（比如ContactInfo或者FinanceInfo）两个数据模型类？谢谢！

Answer 1

“实际情况中”，既然你通过分析认为将信息分开是比较合理的，那么查询信息通常也是分开的。例如查询到List<Account>、List<Contactinfo>、List<FinanceInfo>等等，分开查询，没有必要合并。

Answer 2

难道你不知道延迟加载么？class Account
{
    public int ID { get; set; }
    ...
    public ContactInfo Contact
    {
        return db.Contacts.Where(x => x.AccountID == this.ID).Single();
    }
}
这样，只有你在使用account.Contact去访问的时候才会执行真正的查询。如果你要返回多个对象，可以试试看Tuple
和KeyValuePair不同，Tuple最多允许你组合8个不同类型的数据。
http://msdn.microsoft.com/zh-cn/library/system.tuple(v=VS.95).aspx

Answer 3

多个方法都返回List<Account>，每个方法根据情况获取需要的信息，并对相应的属性赋值，不想要的属性就直接赋null。
但是往往业务上需要返回的是账户的某几块信息，不单单是其中的一块信息。
所以一定是需要Account和其他信息的组合。

Answer 4

首先呢 我没有采用mvc 其次呢 数据模型类只是负责存放数据 没有方法

Answer 5

我只是演示了延迟加载，和mvc没有任何关系。你可以在getter里面放入用ado.net访问数据库的逻辑，或者别的逻辑也是可以的。如果你想使用失血的模型（也就是模型不包含方法），你也可以使用享元模式，配合lazy load。

Answer 6

Account、ContactInfo、FinanceInfo读取数据库是分开读取的，没有表连接，并且这三块信息都使用了缓存组件。这么晚了也难道有高手在，我索性就罗嗦一下。用has a的模式将ContactInfo和FinanceInfo作为Account的属性，和用keyvaluepair或者tuple的方式，以您的经验来看，哪种更灵活？
再或者用另外一种方法，Account、ContactInfo、FinanceInfo都是独立开来，先获取List<Account>，然后遍历的时候再获取需要的Contact或者FinanceInfo。

Answer 7

设想你是一个调用这个数据API的程序员，你喜欢什么样的API？我想我更喜欢符合约定和逻辑，不需要了解额外信息（比如数据库是什么结构，这些实体是什么关系等等），调用代码足够简单，不用看文档也知道参数和返回值含义（如果你用了KeyValuePair或者Tuple我得查手册，Key是什么，Value是什么，Item1是什么，Item2是什么……）。

Answer 8

感觉你们俩儿说的有点矛盾了。
我具体点说吧，aspx调用bll，bll是直接返回把Account、ContactInfo、FinanceInfo打包好的List数据呢？还是bll创建3个返回list的方法和3个返回单个Model的方法，然后在aspx组合调用？

Answer 9

又是一个分不清楚 DO,VO，BO，PO,DTO 区别的
我可以很负责任的说，你们的设计其实是相当不错的设计问题不在设计师身上，问题反而在程序员身上。程序把PO认为是BO了，这是不对滴。从你的问题看，如果Bil认为需要有一个把3个组合起来的BO，那有啥问题呢？逻辑需要那就去做。老p认为的和我们没有啥不同，也不存在矛盾。一切以实际逻辑为准，实际逻辑如果一定需要一个组合对象，那么就组合一个对象，如果实际逻辑说其实很多时候不一定需要组合，那么提供3个单独的对外服务也没问题其实我们就一句话“不要纠缠非要从一而终的所谓实体，一切从对外系统服务出发，当把po弄成Bo的就弄，当需要vo那就给个vo”

Answer 10

我这个程序只有一种数据模型对象，采用传统的三层架构，层与层之间用接口通信，数据模型对象作为参数。没有涉及到你说的bo，dto等等这么多东西。

Answer 11

基本无语，合着白说了啥就，三层架构，层与层之间用接口通信，数据模型对象作为参数ok，这一句话你就已经说明白了，你自己都说了，你把PO直接当BO使了，却自己郁闷我砸没有BO呢？？PO的考量和BO的考量，根本就是2个套路。PO考量的是查询效率，BO考量的业务逻辑，自然就不是一个东西。自己想一下区别？
提示：你想一下BO里一个对象，一部分数据在数据库里，一部分数据在xml里。 这时候你还号称什么数据模型对象做参数吗？那部分xml数据都根本不在你数据库里，你拿什么做参数？？

Answer 12

对象视图是图状的，返回你需要的关键节点就行了，其它的节点可以一层一层去get

Answer 13

好吧 您老先息怒 别伤到身体了 小弟（也可能大哥）不才 再麻烦你费点儿心 说到数据分开存放在xml和db 我觉得也应该是Account、ContactInfo和FinanceInfo分开存放有这个可能 不大会Account、ContactInfo或FinanceInfo里的某一个的属性分开存放。petshop的三层之间都是调用接口，层与层之间的数据交换都是用实体类。对业务封装的class在业务层里也只是对某一小块业务的封装（比如购物车），况且这个封装的类也不会再层与层之间传递调用。
按照您的意思，是不是应该bll和dal数据交换用po，而ui和bll之间交换用bo更合适？

Answer 14

原以为只有java才有那么多O转来转去（也不嫌累），什么时候.net也中这种病毒了。