1

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

情况1

例如，一个用户属于一个城市，它又属于一个州和一个国家，, User,City是我的数据库中包含很多字段的表，但我想要一个包含订单列表的用户列表，所以我创建一个名为例如仅具有重要属性 ( ) 的业务对象，我的 DAL 仅从数据库中检索该字段。StateCountryUserWithOthersUserId, UserName, CityName, StateName, CountryName, List<Order>

案例2

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

我曾想过一些选择：

  1. 制作这两个业务类并在每个 DAL 方法中分别填充它们（这个对象很简单，但考虑到该方法可能有一个复杂的选择查询，需要封装以供重用，因此存储库模式在这里不太适合，至少我认为）。
  2. 只创建一个User具有所有属性的UserId, UserName, CityName, StateName, CountryName, OrdersCount, List<Order>对象（所有耦合。
  3. 如果我稍后在另一个视图中需要，选项 1 不能很好地处理，两者List<Order>和OrdersCount属性。
  4. 现在考虑一下，如果您使用 ASP.NET MVC 良好实践告诉您需要一个 ViewModel 来传递给视图，我想从我的 Businnes 层返回 ViewModels，但我认为这不是一个好主意，感觉就像我是违反某些东西，也是不可能的，因为我的业务层在另一个程序集中而不是 Web 应用程序中。
  5. 我不想一遍又一遍地编写相同的 Linq 查询，但如果使用 NHibernate 或 EFCodeFirst 是“喜欢”选项之一，我将需要创建大量小型业务对象。

你如何处理这种情况？我认为这是一个高级别的设计决策。

4

1 回答 1

2

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

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

  2. 不要从业务层返回 ViewModel；您的业​​务层应该代表您的应用程序域的业务概念，而 ViewModel 是一个数据对象，其中包含显示该域某个部分的特定视图所需的数据 - 两者是非常不同的东西，业务层应该完全不知道它的业务对象用于任何类型的 GUI。

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

于 2011-06-02T15:09:27.227 回答