具有多个对象的业务层，这些对象具有从DB填充的所有属性或仅填充子集的一个对象

Question

我正在建立一个中等规模的系统，我正面临着一个可能你们中的一些人以前遇到过的问题。在我的业务层中，我返回具有对该业务方法很重要的属性子集的业务对象，我很担心，因为我最终可能会得到许多具有无意义名称的对象，或者只有一让我举个例子。

个案一

例如，用户属于一个城市，该城市又属于一个州和一个国家, User, City, State 和 Country 我的数据库上有很多字段的表，但是我想要一个带有订单列表的用户列表，所以我创建了一个名为example的业务对象 UserWithOthers 只有重要的属性（UserId, UserName, CityName, StateName, CountryName, List<Order>）而我的DAL只从数据库中检索该字段。

个案二

我想现在返回一个订单量的用户，我在我的业务对象中以以下字段结束（UserId, UserName, CityName, StateName, CountryName, OrdersCount）和类可以调用例如 UserWithOrderCount

我想过一些选择:

1. 制作两个业务类，并在每个DAL方法中分别填充它们（此对象很简单，但考虑到该方法可能有一个复杂的select查询，需要封装以便重用，因此repository pattern不适合在这里，
2. 只创建一个对象 User 与所有的属性（UserId, UserName, CityName, StateName, CountryName, OrdersCount, List<Order>）并且在每个DAL方法中只填充一个子集，但是当你使用一个方法时，这意味着语义耦合，因为你必须知道哪个字段子集是从数据库中填充的，而语义耦合是所有耦合中最差的。
3. 选项1不能很好地处理，如果我以后需要在另一个视图中，两者, List<Order> 和 OrdersCount 属性。
4. 现在考虑一下，如果你使用ASP.NET MVC良好的实践告诉你需要一个ViewModel传递给视图，我想从我的业务层返回Viewmodel，但我不认为是一个好主意，感觉我违反了一些东西，也是不可能的，因为我的业务层
5. 我不想一遍又一遍地编写相同的Linq查询，但是如果使用NHibernate或EFCodeFirst是"喜欢"选项一，我将需要创建大量的小型企业对象。

你如何处理这种情况？我认为这是一个高层次的设计决定。

Answer 1

首先，我绝对同意你的一些事情不做:

1. 不要部分填充业务对象，因为您将负责知道哪些属性填充到业务层的客户端上，这是非常糟糕的做法。

2. 不要从业务层返回ViewModels;您的业务层应该代表应用程序域的业务概念，而ViewModel是一个数据对象，其中包含显示该域某个部分的特定视图所需的数据-这两者是非常不同的事情，业务

我会用你的第一个建议去-创建一个单独的业务对象来表示每个业务概念。然后，我会使用ORM（如EF或NHibernate）为我填充这些对象，并为每组对象提供专用存储库。然后，我会使用一个应用程序层，它调用存储库来返回所需的任何对象。为此，您的存储库可以包含在您知道需要将这两种类型一起使用时返回已加入用户和订单的方法。这允许您在一个查询中返回用户及其所有订单，同时保留单独的有意义的实体来表示用户和订单。