如何构建企业MVC应用程序，以及Business Logic在哪里？

Question

我是MVC新手。据我所知：

• 控制器：处理路由请求
• 查看：处理数据展示
• 模型：看起来很像数据访问层

业务逻辑在哪里？

使用以下内容获取大型企业应用程序：

• 在数据访问层（使用多个不同的DTO）中绑定了几个不同的数据源（WCF，WebServices和ADO）。
• 很多业务逻辑在几个dll上进行了细分。

MVC Web应用程序在此基础上（在代码和项目结构方面）的适当方式是什么？

我已经看到模型文件夹中所有内容的示例似乎不适用于非常大的应用程序。

感谢您的任何建议！

Answer 1

在我的应用程序中，我通常创建一个与Web项目分开的“Core”项目。

核心项目包含：

1. 业务对象，例如实体等
2. 数据访问
3. 任何不专为网络设计的

Web项目包含：

1. 控制器，用于将请求从UI路由到核心逻辑
2. 观看，专注于以HTML格式呈现数据
3. 查看模型，它将核心业务对象展平/转换为旨在支持特定视图的更简单结构

这里的关键点是基于Web的模型文件夹/命名空间仅用于特定于表示的模型，这些模型记录了给定视图所需的特定变量。尽可能多的“业务逻辑”进入核心项目。

Answer 2

M odel V iew C ontroller听起来像它解决了你的3层，但事实并非如此。它确实组织了UI的组合方式。 Controller处于中间位置，通常（A）使用 B usiness对象执行操作，（B）使用 B usiness对象获取 M odel对象传递给 V iew。系统的MVC部分（UI功能）不知道业务层的另一端发生了什么。 D B？服务电话？磁盘IO？射击激光器？那么， MVC-B - ？将是一个描述MVC 和它如何挂钩的首字母缩略词。

想一想中间的 C ontroller，一行 down 到 B usiness对象。控制器通常会从 B usiness对象中获取 M odel以传递给 V iew，但是 M odel只是数据。这是关键。从某种意义上说， C ontroller现在是系统的 smartest 部分，但 B usiness对象仍然是最强大的。

因此， M odel对象是 C ontroller和 B usiness对象之间通信的很大一部分。此外，每个视图都有一个 VM （ V iew M odel）对象，可能是 M odel，但可能是由 C ontroller构建的，用于将更复杂的信息集传递给 V iew。

因此，一个控制器（ 1 ）从客户端获取数据并使用业务对象（如果需要），使用模型对象进行通信，然后（ 2 ）从 B usiness对象中获取 M odel对象，构建 VM ，并将其提供给视图（可能的几个）渲染。

起初它看起来真的像层和层一样，特别是因为进入MVC是增加接口使用的好时机（参见最后3或4 Solid principals）和{{3} }。您的项目中可能会有更多文件，而不是其他方式。很快，虽然你看到这实际上是组织事物的好方法。

作为系统的这个“顶层”部分，MVC部分，我们不关心 M odel对象是如何构建的，或者 B usiness对象是做什么的跟他们。如果您的 Customer 模型对象看起来与您的 Customers db表非常相似，请不要感到惊讶！这是正常和常见的。但是，您的客户 M odel对象和您的客户 B usiness对象将真正具有不同的生命。现在是考虑unit testing的好时机。

对抗懒惰的诱惑，并在 C ontroller中加入大量逻辑。随时努力将关注点放在他们下面的地方。 C ontroller仅用于接线。如果需要大量代码来构建足够的 VM 以供视图使用，这是可以的，因为这是控制器作业。您经常在控制器中看到业务逻辑或渲染逻辑。把它放在它所属的地方！

我试图平衡全面性和简洁性，但你提出了一个很大的问题！

Answer 3

MVC不是一个满足您需求的完整架构，它只涵盖表示层。您的控制器应该与业务层和模型对象进行对话。业务层可以与其他层进行通信，如数据库访问，Web服务，文件系统等。

Answer 4

我倾向于将我的业务逻辑放在服务中，并从控制器中调用它们，控制器将数据整理并发送到适当的服务。

要让MVC应用程序位于其上，我会使用外观模式或类似的东西来代理对现有业务逻辑的调用。因此，您的服务本质上只是将数据传递给现有业务逻辑。

这样，现有的业务逻辑和基于MVC的新代码之间就会出现干扰。

Answer 5

“它取决于”：）

请求被路由到控制器，控制器会适当地处理它们。控制器是将所有其他东西（模型，视图等）组合在一起的“粘合剂”。因此，“业务逻辑”直接处理或由控制器卸载到另一个组件是很自然的。

你实际把逻辑放在哪里取决于你的需要。如果单个控制器只需要逻辑，那么将它直接放在一个控制器内就可以了。当然，如果需要数据一致性，逻辑也可能会进入单一模型。

或者，您可以将逻辑放在辅助类/函数中，或者（正如其他人提到的那样），您可以为业务逻辑创建服务层。

Answer 6

您可以使用S#arp Architecture使用最佳做法正确构建应用程序。有一个全面的示例应用程序可用于：Who Can Help Me?

Answer 7

也许这个link会帮助您更好地理解模型。它们可以扮演数据传输对象的角色，或者像链接描述的那样更深入。但是，在我看来，它们不应该是你的DAL。我看到的许多例子都处理了业务逻辑和DAL与服务＆amp;存储库模式。

检查MVC Contrib Project和代码阵营示例以获得此示例。

我还找到了Rob Conery的eCommerce Storefront和Northwind MVC starter kit来帮助。

Answer 8

IMO这个场景更适合你在WPF中使用的东西。 ViewModel View Controller。

您的控制器与在域对象上执行功能的业务服务进行通信。控制器将业务服务返回的数据（如果需要，将几个组合）转换为View Models（MVC中的“M”）。然后将视图模型传递给视图。

反之亦然，从视图中获取VM并将数据发送回业务服务