ASP.NET MVC 三层 - 其他人在做什么？
当我开始开发新的 Web 应用程序时，我倾向于使用相同的尝试和方法。经过测试的 ASP.NET MVC 架构、BLL（由一组包含所有业务逻辑的服务组成）和一个 DAL（由一组促进该单元的存储库组成类似于 EF/*Linq to SQL* 的工作模式）。
控制器仅与服务对话，服务仅与存储库和其他服务对话。服务层是定义模型的地方，这些模型被用作控制器的输入/输出。
我的问题是：其他人在做什么？我有兴趣了解人们是否在 ASP.NET MVC Web 应用程序上下文中执行任何不同的操作。例如，诸如CQRS和域事件之类的概念。有人使用这些来解决我上面描述的方法的问题吗？
这个问题主要是试图发现我不知道的东西。我希望这不是太含糊，但我认为看看其他人在做什么来评估你自己的方法很重要。
When I start work on a new web application I tend to reach for the same tried & tested architecture of ASP.NET MVC, BLL (consisting of a set of services that contain all business logic) and a DAL (consisting of a set of repositories that facilitate the unit of work pattern over something like EF/*Linq to SQL*).
The controllers talk only to services, the services only to repositories and other services. At the service layer are where models are defined and these are used as input/output to/from the controllers.
My question is: what are others doing? I'm interested in knowing if people are doing anything different in the context of an ASP.NET MVC web application. For instance, there are concepts like CQRS and Domain Events. Is anyone using these to solve a problem with the method I've described above?
This question is mainly a source of attempting to discover what I don't know I don't know. I hope it's not too vague, but I think it's important to see what others are doing to evaluate your own methods.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们基本上正在做您正在做的事情，除了我们将存储库接口视为服务（它们在业务层中定义），因此我们的控制器通常直接访问它们。 IoC 容器负责通过构造函数注入注入正确的存储库实现。因此数据层依赖于业务层，并负责实现存储库，而业务层只是假设它定义的所有存储库在运行时都可用。
我们将产品进一步划分为不同的功能模块。有些模块相互依赖（例如，一切都依赖于我们的核心功能，而大多数其他模块依赖于门户网站模块），但是将它们保留在单独的 dll 中可以帮助我们避免使这些模块过于紧密地耦合。因此，系统只能加载给定客户端已付费的模块的 DLL。我们计划使用事件总线以及核心模块中定义的事件，以允许模块通过发布/订阅模型进行通信。
We're basically doing what you're doing, except that we consider our repository interfaces to be services (they are defined in the business layer), and therefore our controllers often access them directly. An IoC container takes care of injecting the correct repository implementation via constructor injection. So the data layer depends on the business layer, and is in charge of implementing the repositories, while the business layer just assumes that all the repositories it has defined will be available at runtime.
We've further divided our product up into different modules of functionality. Some of the modules depend on one another (for example, everything depends on our core functionality, and most of the other modules depend on the web portal module), but keeping them in separate dlls helps us to avoid making these modules be too tightly coupled. The system can therefore only load the DLLs for the modules that a given client has paid for. We plan to use an event bus with events defined in the core module to allow the modules to communicate via a publish/subscribe model.
我将 CQRS 与 MVC 结合使用。很好。您仍然使用 MVC 模式，但在控制器中我使用命令模式进行写入，仅使用纯 NHibernate Linq 进行读取...还有一些 SolrNet 进行读取。 :-)
I am using CQRS with MVC. Its nice. You still use the MVC pattern, but in the controller I use the command pattern for the write, and just pure NHibernate Linq for the read... also some SolrNet for the read. :-)