当前位置：文江博客话题详情

ASP.NET MVC - 我认为我的做法是错误的

发布于 2024-10-18 21:18:03 字数 535 浏览 1 评论 0原文

或者我根本不明白这一点。

我已经使用控制器启动了 ASP.NET MVC 应用程序 -->视图模型 -->服务-->存储库模式。

是否每种类型的对象（客户、产品、类别、发票等）都需要拥有自己的存储库和服务？如果是这样，您如何将常见的物品放在一起？

我的意思是，很多时候其中一些内容会显示在同一页面上。所以我不明白这一点，我不认为。

所以我想我需要一个 ShopController，它有一个 ShopViewModel，它可以有类别、子类别、产品等。但对我来说，问题是它似乎不太适合。

也许 ASP.NET WebForms 适合像我这样的人:)

编辑

那么聚合是否会包含以下内容：

类别、子类别、产品、ChildProduct、ProductReview，其中 Product 是聚合根？

然后在 ViewModel 中，您将访问 Product 以获取其子产品、评论等。

我使用的是实体框架 4，那么如何使用存储库/服务模式实现延迟加载？

原文

分享到QQ

分享到微博

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

发布评论

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

岁吢 2024-10-25 21:18:03

每种类型的对象（客户、
产品、类别、发票等..）
需要有自己的存储库

您域中的每个聚合根都应该有一个存储库。请参阅此问题，了解有关什么是聚合根的更多信息。

在您给出的示例中，我可以看到一个 CustomerReposiotry 它将处理检索所有相关的客户数据（客户有订单，订单有客户）。处理检索产品信息的 ProductRepository。

还有服务？如果有的话，怎么带
共同的物品放在一起？

服务层很好，但前提是添加该层能带来附加值。如果您的服务只是直接传递到存储库，则可能不需要它。但是，如果您需要在产品上执行某些业务逻辑，那么 ProductService 可能会有意义。

这可能没有意义

public void UpdateProduct(Product product)
{
  _repo.Update(product);
}

，但是如果您有逻辑，那么这一层对于封装产品的业务规则是有意义的。

public void UpdateProduct(Product productToUpdate)
{
  //Perform some sort of business on the productToUpdate, raise domain events, ....
  _repo.Update(productToUpdate);
}

所以我想我需要一个
ShopController，它有一个
ShopViewModel，可能有
类别、子类别、产品、
等等。但对我来说，问题是
它只是看起来不太协调。

如果域被刷新，视图模型最终有意义

public ActionResult Index()
{
  ShopViewModel shopViewModel = new ShopViewModel();
  shopViewModel.Products = _productRepo.GetAll();
  //other stuff on the view model.
  return(shopViewModel);
}

更新

当您还需要时会发生什么
提供无法从
聚合根?例如，说我
有一个创建客户视图并在
那个观点，我还需要提供
用户与公司集合
选择关联一个新的
客户与.是否采集到
公司来自 CustomerRepository
或者您还需要一个
公司存储库？

如果一家公司可以独立存在（例如，您编辑、更新、删除一家公司），我建议公司也是您域的聚合根（客户有一家公司，一家公司有一个客户列表）。但是，如果只能通过客户获得公司，我会将公司视为 ValueType/Value 对象。如果是这种情况，我将在客户存储库上创建一个方法来检索所有公司名称。

_repo.GetAllCompanyNames();

Does every type of object (Customer,
Product, Category, Invoice, etc..)
need to have it's own repository

You should have a repository per aggregate root in your domain. See this question for more information on what is an aggregate root.

In the example you give I could see a CustomerReposiotry which would handle retrieve all pertinent customer data(Customer has orders a order has a customer). A ProductRepository that handles retrieving product information.

and service? If so, how do you bring
common items together?

A service layer is nice but only if there is added value in adding this layer. If your service simply passes straight into the repository it might not be needed. However if you need to perform certain business logic on a Product a ProductService might make sense.

This might not make sense

public void UpdateProduct(Product product)
{
  _repo.Update(product);
}

But if you have logic this layer makes sense to encapsulate your business rules for products.

public void UpdateProduct(Product productToUpdate)
{
  //Perform some sort of business on the productToUpdate, raise domain events, ....
  _repo.Update(productToUpdate);
}

So I was thinking I need a
ShopController, which has a
ShopViewModel, which could have
categories, sub categoires, products,
etc. But the problem, for me, is that
it just does not seem to mesh well.

If the domain is flushed out the view model ends up making sense

public ActionResult Index()
{
  ShopViewModel shopViewModel = new ShopViewModel();
  shopViewModel.Products = _productRepo.GetAll();
  //other stuff on the view model.
  return(shopViewModel);
}

Update

What happens when you also need to
provide data unobtainable from an
aggregate root? For example, say I
have a create Customer view and in
that view, I also need to provide the
user with a collection of Companies to
choose from to associate a new
customer with. Does the collection of
Companies come from CustomerRepository
or would you also need a
CompanyRepository?

If a Company can live by itself (e.g. you edit, update, delete a company) I would suggest a Company is also an aggregate root for your domain (A Customer has a company and a company has a list of Customers). However if a Company is only obtainable via a Customer, I would treat a company as a ValueType/Value Object. If that is the case I would create a method on the customer repository to retrive all CompanyNames.

_repo.GetAllCompanyNames();

回复收藏 0 原文

就是爱搞怪 2024-10-25 21:18:03

存储库是必不可少的，跟着他们走就行了。他们隐藏了数据实现。与 ORM 一起使用，您几乎可以忘记核心数据库活动 (CRUD)。您会发现对象和存储库之间通常存在 1:1 映射，但没有什么可以阻止存储库返回它喜欢的任何内容。通常，您会根据实例采取行动。为不适合现有查询的查询创建非对象特定存储库。

您会发现关于“服务”部分的许多相互矛盾的论点 - 有些人喜欢将其划分为领域服务（我将这些业务规则称为不适合核心域对象的业务规则）和应用程序服务（域对象上的操作的逻辑分组）。实际上，我已经选择了一个名为 [ProjectName].Core.Operations 的独立项目，该项目位于我的 [ProjectName].Core 解决方案文件夹中。核心+运营=领域。

操作可能会返回视图所需的所有信息的 DTO，这些信息是通过域上的许多存储库调用和操作构建的。有些人（包括我自己）更喜欢从演示中完全隐藏存储库，而是使用操作（服务）作为它们的外观。只要凭直觉命名，不要害怕，重构是健康的。 HomePageOperations 类没有任何问题，方法 GetEveryThingINeedForTheHomepage 返回 ThingsINeedForTheHomePage 类。

使控制器的重量尽可能轻。他们所做的就是将数据映射到视图，将视图映射到数据，与“服务”对话并处理应用程序流程。

下载并查看 S#arp 架构或谁可以帮助我项目。后者确实展示了一个很好的架构恕我直言。

最后不要忘记层的主要关注点之一是可插拔性/可测试性，所以我建议您考虑一个好的 IoC 容器（我是 Castle.Windsor 的粉丝）。同样，S#arp 架构是查找此内容的好地方。

回复收藏 0 原文