我可以从表示层访问存储库吗？
我从 DDD 开始。我对 DDD 应用程序中涉及的几个层之间的交互有点困惑。
我可以从表示层调用我的存储库吗？如果不是，我是否必须在我的服务层中复制存储库提供的 CRUD 功能（当然，服务层将反过来使用这些功能的存储库）？最好的方法是什么？
I am starting with DDD. I am a bit confused with the interaction between the several layers involved in a DDD application.
Can I call my repositories from my presentation layer? If not do I have to replicate the CRUD functionality provided by the repositories in my service layer (which ofcourse will in turn use the repository for these functions)? What would be the best way to do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
表示层到底是什么意思？
如果您指的是控制器/演示者，那么就完全没问题了。我使用的经验法则是，如果控制器操作是 4 行或更多代码，我应该考虑重构为应用程序服务类，但仍然 - 两者都处于应用程序级别，您当然可以在那里使用存储库。
您表达问题的方式（我当然可能会误解这一点）听起来很可疑，就像您正在考虑从视图或代码隐藏中引用存储库一样。那样的话我会说不！不！不！
What exactly do you mean by presentation layer?
If you mean the Controller/Presenter, then it's perfectly fine. The rule of thumb that I've used is if the controller action is 4 lines of code or more I should look at refactoring to an application service class but still - both are at the application level and you can certainly use repositories there.
The way you phrased your question - and I could certainly be misinterpreting this - sounded suspiciously like you were thinking of referencing the repository from your view or codebehind. In that case I would say no! no! no!
当然，您可以从表示层调用存储库。我的一个建议是让表示层依赖于存储库的抽象而不是实现，即 UserSession 依赖于 IPersonRepository 接口而不是 PersonRepository 类。它不仅可以很好地分离关注点，而且可以使测试变得更容易。
大胆试试吧！
Absolutely, you can call a repository from the presentation layer. My one piece of advice is to have your presentation layer depend on an abstraction of a repository as opposed to the implementation, i.e. UserSession depends on an IPersonRepository interface instead of a PersonRepository class. Not only is it a good separation of concerns, but it can make testing easier.
Go for it!
嗯，我通常使用服务层，但使用你的存储库没有坏处
Well I usually use a service layer but there is no harm in using your repository
正如 Kevin 所说，使用控制器或演示器会给您带来很多好处。
其中包括明确的关注点分离以及可测试性。
就个人而言，在 ASP.NET 设置中，我会选择“被动视图”Fowler 。
您只需将页面契约设计为具有 Web 表单等具体实现的接口，然后在测试演示者时只需存根/模拟它们。
我想到的唯一缺点是，与“传统”Web 表单解决方案相比，您最终会得到更多的代码。
As Kevin says, going with a controller or presenter gives you many benefits.
These includes clear separation of concerns as well as testability.
Personally, in an ASP.NET setting, I'd go for a «passive view» Fowler.
You simply design your page contracts as interfaces which have concrete implementations as web forms, and then you just stub/mock those when testing your presenters.
The only drawback that comes to mind is that you end up with more code than in a "traditional" web form solution.