控制器处理应用程序流，那么我的业务逻辑在哪里？
在开始这个问题时，我承认我对 MVC 很陌生。 该设计模式在高层次上对我来说很有意义，但现在我正在探索 ASP.NET MVC，一些架构部分正在挑战我先入为主的观念。 学习是一件好事。
我最近一直在使用 Oxite 作为 公司创建了 ASP.NET MVC，因此表面上是 ASP.NET MVC 的参考应用程序。
但今天我看到 Rob Conery 的一篇关于 Oxite 的博客文章说：
Oxite 团队所做的事情之一 决定做的就是分开 控制器和视图到另一个 我只能假设的项目是 将业务逻辑与 查看逻辑。 这可能会导致一些 混乱，因为控制器的意思是 处理应用程序流程 - 不 必然是业务逻辑。
这让我陷入了困境。 这种分离是 MVC 的原则，因此是 Oxite 开发人员的错误，还是 Rob 的观点？ 如果业务逻辑属于模型，为什么 Oxite 团队将其放在控制器中？ 如果不在控制器中，如何执行业务逻辑的操作？
除此之外，考虑到像 Rob 这样的评论，我使用 Oxite 作为学习基准是否犯了一个错误？
I will begin this question by admitting I am very new to MVC. The design pattern makes sense to me at a high level, but now that I'm exploring ASP.NET MVC, some of the architectural pieces are challenging my preconceived notions. Learning is a good thing.
I've been working with Oxite lately as a learning tool written by people at the company that created ASP.NET MVC and thus, an ostensible reference application for ASP.NET MVC.
But today I saw a blog post about Oxite by Rob Conery that says:
One of the things that the Oxite team
decided to do was to separate the
Controllers and Views into another
Project for what I can only assume is
the separation of business logic from
view logic. This can lead to some
confusion since Controllers are meant
to handle application flow - not
necessarily business logic.
This has thrown me for a loop. Is this separation a tenet of MVC and thus a mistake by the Oxite developers, or is it Rob's opinion? If the business logic belongs in the model, why did the Oxite team put it in the controller? How do I execute an action that is business logic if not in the controller?
Further to that, am I making a mistake using Oxite as a learning benchmark considering comments like Rob's?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的业务逻辑位于您的业务层中。 控制器使用业务层创建模型供视图渲染。 Rob Conery 制作的 MVC Storefront 应用程序就是一个很好的例子。 Oxite 目前受到了很多负面报道，因为它显然没有很好地利用 MVC 框架。
您希望业务层与控制器分离的原因是您可能希望跨多个控制器甚至多个应用程序重用业务层。 例如，用于显示数据的普通用户功能以及用于更新和添加数据的管理功能。 在这两种情况下，您可以使用相同的 BL 组件，但具有不同的控制器和视图来呈现数据。 模型对象是相同的。
Your business logic goes in your business layer. The controllers use the business layer to create a model for your views to render. A good example is the MVC Storefront application that Rob Conery has produced. Oxite is currently getting lots of bad press as it apparently does not make good use of the MVC framework.
The reason that you want a business layer that is separate from your controllers is you may want to reuse the business layer across multiple controllers, or even multiple applications. An example of this would be normal user functions for displaying data, and administrative function for updating and adding data. You may make use of the same BL components in both cases but have different controllers and views to render to the data. Model objects would be the same.
您可以使用实体、聚合、存储库和服务来实现业务层（即模型）。 这些服务调用存储库，存储库以实体的形式从 DAL 中提取数据。
这可以在一个单独的项目中设置，该项目只不过是一个 DLL。
接下来，让您的 MVC 应用程序（实际上是您的表示层）并让它利用您的业务层项目。 控制器将与您的服务一起工作，并将这些服务生成的数据泵入 ViewData，然后将其泵入您的视图。
控制器应该只处理路由问题，例如根据来自表单、查询字符串、cookie、会话等的用户输入来显示哪些视图。
“MVC 纯粹主义者”社区对所使用的 Oxite 的有效性引起了轩然大波。一个很好的 MVC 示例。 最重要的是，业务逻辑不应包含在控制器中，我相信随着 Oxite 在未来几个月的重构，您会看到这一点。
You could implement your business layer (i.e. the Model) with your entities, aggregates, repositories, and services. The services call the repositories, which pull data from your DAL in the form of entities.
This can be set in a single, seperate project which is nothing more than a DLL.
Next, have your MVC App, which is really your Presentation layer, and have it utilize your business layer project. the controllers will work with your Services, and pump the data those Services generate into ViewData which is then pumped into your Views.
The controllers should only deal with routing concerns, such as which views to display, based upon user input from forms, querystrings, cookies, sessions, etc.
there has been an uproar from the "MVC purists" community about the validity of Oxite being used an a good MVC example. The bottom line is, business logic should not be contained in controllers, which I am sure you will see as Oxite gets refactored over the coming months.