Asp.net mvc 中应该有服务层吗？
Asp.net MVC 中控制器和存储库之间是否应该有一个服务层？由于存储库仅用于数据访问。一些业务逻辑被泄露到Controller中。如果经典的 Asp.Net 客户端使用相同的操作，这可能会产生问题，因为我们必须在控制器中复制逻辑。
Should there be a Service Layer in Asp.net MVC between Controller and Repository? As Repository is there for only Data Access. Some business logic is leaked into Controller. This might create a problem if the same operation is used by classic Asp.Net client as we have to duplicate the logic in Controller.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您严格遵循领域驱动设计，您会发现有3 种类型的服务（您不喜欢过多的术语吗？）。
听起来您需要域服务来封装/共享您的业务逻辑。
希望有帮助！
If you follow Domain Driven Design to the letter, you'll find that there are 3 types of service (don't you love overloaded terms?).
Sounds like you need Domain Services to encapsulate/share your business logic.
Hope that helps!
说实话，我在这方面采取了两种方式。我目前的观点是，存储库是一种服务，它只是一种恰好负责处理域聚合根的 CRUD 操作的服务。现在，如果你的“存储库”与你的实体直接 1:1 映射（因此，不是存储库，而是 DAO），那么我就可以看到这个论点。但一般来说，我会根据需要添加抽象层，但直到证明给定应用程序需要它们为止。否则，你就会过度设计。
TBH, I've gone both ways on this. My current perspective is that a Repository is a service, it's just a service which happens to have the job of handling CRUD ops for a domain aggregate root. now, if you're "repositories" are directly mapped 1:1 with your entities (and therefore, not repositories so much as DAOs') then I could see the argument. But generally, I add layers of abstraction as needed, but not until proven that they're needed for a given app. Otherwise, you over-engineer.
我喜欢服务层在控制器和存储库之间提供的额外抽象级别。我觉得它对于履行单一职责原则有很大帮助。
I like the extra level of abstraction a service layer provides between my controllers and repositories. I feel it helps tremendously in fulfilling the Single Responsibility Principle.
我对此进行了一些尝试。我正在构建的应用程序非常适合 CRUD，并且我的服务层最终公开了与我的存储库几乎相同的接口。此外，大多数服务调用没有在存储库之上添加任何额外的逻辑，它们只是传递方法。服务层唯一做任何事情的地方是在更新或插入新记录期间。 我认为，在基于 CRUD 的系统中，服务层造成的摩擦多于其增加的价值。我最终扩展了我的业务模型类，以便将服务逻辑公开为针对模型的操作，从而使我的控制器方法保持精简和干净。
然而，在更加行为驱动的系统中，我认为服务层可能会增加更多价值。
I experimented with this a little bit. The app I was building was pretty CRUD-y, and my service layer ended up exposing nearly the same interfaces as my repositories. In addition, most of the service calls didn't add any extra logic on top of the repo, they were just pass-through methods. The only place where the service layer did anything was during an update or insert of a new record. I decided that in a CRUD-based system, the service layer caused more friction than it added value. I ended up extending my business model classes so that the service logic was exposed as operations against the model, thus keeping my controller methods lean and clean.
In a more behavior-driven system, however, I think a service layer might add more value.
我强烈建议使用服务层，以便您可以在不同的 Web 应用程序之间共享通用功能。可能的情况是该架构已经存在，并且您可能想在前端添加一个新的 mvc 网站。
对于从头开始构建的简单架构来说，这可能有点过分了。
I highly recommend using a service layer so you can share common functionality between different web applications. It maybe a case that the architecture is already in existence and you may want to add a new mvc website on the front end.
For simple architectures built from scratch it maybe overkill.
在大多数情况下，我喜欢将存储库直接放在控制器中，并在我觉得有泄漏的地方创建一个服务。我尝试拥有丰富的域对象，但在逻辑不适合域类的情况下，我会创建一个服务。
I like to have repositories directly in the controller in most cases, and make a service where I feel it leaks. I try to have rich domain objects, but in those cases where logic doesn't fit in the domain classes, I create a service.