使用存储库模式处理视图

发布于 2024-11-05 02:31:26 字数 751 浏览 0 评论 0原文

使用存储库模式处理视图(不代表实体但用于绑定下拉列表等的类)的最佳方法是什么?例如,我有一个以下客户实体

public class Customer {
  Guid ID {get;set;}
  string FirstName {get;set;}
  string LastName {get;set;}
  List<Address> Addresses {get;set;}
}

和一个存储库,

public class CustomerRepository : IRepository<Customer> {
   Customer GetByID(Guid id) { ... }
   List<Customer> GetAll() { ... }
   // Insert/Delete/Update Customer etc.
}

现在我想使用客户的 ID 作为值属性,用客户列表及其基本地址填充 DropDown。我有一个返回此数据的存储过程,我可以将其结果检索到以下对象列表中:

public class CustomerWithBaseAddress {
  public Guid CustomerID {get;set;}
  public string FullNameWithBaseAddress { get;set; }
}

客户存储库应该返回此类对象还是应该由不同的专用存储库管理(但没有保存/删除操作)?

What is the best way to handle views (classes that does not represent entities but are used, for instance, to bind a DropDown-list) using a repository pattern? For instance I have a following Customer Entity

public class Customer {
  Guid ID {get;set;}
  string FirstName {get;set;}
  string LastName {get;set;}
  List<Address> Addresses {get;set;}
}

and a repository

public class CustomerRepository : IRepository<Customer> {
   Customer GetByID(Guid id) { ... }
   List<Customer> GetAll() { ... }
   // Insert/Delete/Update Customer etc.
}

Now I want to fill a DropDown with a list of customers along with their base address, using their ID's as a value property. I have a stored procedure returning this data and I can retrieve its result into a list of following objects :

public class CustomerWithBaseAddress {
  public Guid CustomerID {get;set;}
  public string FullNameWithBaseAddress { get;set; }
}

Should Customer repository return such objects or should it be managed by a different, specialized repository (but without Save/Delete operations) ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

北城半夏 2024-11-12 02:31:26

存储库应该只处理聚合根及其聚合。这意味着它可以处理 CustomerCustomerOrders 等。

但是 CustomerWithBaseAddress 是一个 ViewModel,与数据库无关。它应该使用存储库构建在您的控制器中。

您可以使用 AutoMapper 或类似工具进行映射。

A repository should only handle an aggregate root and it's aggregates. This means that it could handle Customer, CustomerOrders etc.

A CustomerWithBaseAddress however is a ViewModel and has nothing to do with the database. It should be built in your controller by using repositories.

You could use AutoMapper or similar for the mapping.

水晶透心 2024-11-12 02:31:26

如果您需要这样的不属于域的对象,并且从域对象组装它们的成本太高,请创建查找服务。基本上只是一个在单独的程序集中调用特殊存储库的服务,该程序集不属于正式域模型的一部分。只要您仅使用从此服务获取的对象作为查找等,它们就是一次性的,不需要管理。

然而,对于可能被误用为域对象的对象使用此方法时必须小心。确保除了从下拉列表中进行选择等之外,不要将 CustmerWithBaseAddress 用于任何其他用途。因此,一旦选择了 CustmerWithBaseAddress 对象,您就应该获得真正的 Customer 对象,并且不要让 CustmerWithBaseAdress 泄漏到应用程序代码的其余部分中。

If you need objects like this that are not part of your domain and it is too expensive to assemble them from domain objects, create a lookup service. Basically just a service that calls a special repository in a separate assembly that is not part of your formal domain model. As long as you are only using the objects obtained from this service as lookups etc they are throwaways and do not require managing.

You have to be careful about using this approach with objects that can be misued as domain object however. Make sure you do not use the CustmerWithBaseAddress for anything other than selection from a dropdown etc. So as soon as you have selected the CustmerWithBaseAddress object you should get the real Customer object and not let the CustmerWithBaseAdress leak out into the rest of the application code.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文