0

在我从事的较旧的 Web 项目中，我们曾经在 DAL 中创建模型，在业务逻辑层中添加 DAL 的引用（并重用来自 DAL 的模型，因为它们可以通过 DAL 的引用获得），在服务中添加 BL 的引用（再次重用模型）。实体在所有连续层中都是可传递的。

在具有多个层的 MVC 项目中，模型通常被添加到单独的类库项目中，并在 DAL、业务逻辑、服务、前端等所有层中引用；即使它们是可传递的。

这样做有什么具体原因吗？为什么我们不应该像下面这样在前端绑定通过服务可用的模型

@model List<TestSolution.TestServiceRef.Employee>

代替

@model List<TestSolution.Models.Employee>

在所有层中分别引用模型与从另一个/上一层的引用中使用它相比有什么优势？

4

1 回答 1

0

我没有很多 MVC 经验（就 ASP.Net MVC 而言），但据我了解，MVC 中的模型只是编码理解它的数据结构的表示（即在运行时） - 并且是'不一定是底层数据本身（即数据库）。

如果您有一个想要在 UI 中表示的概念，那么显然 UI 需要知道该概念是什么——因此在该级别（以及其他诸如业务逻辑等）引用它。在 MVC 之前，我遵循了一种方法/架构，其中“模型”只是一堆 POCO（普通的旧类对象 - .e. 非常简单的哑类或结构）。

这些 POCO 可以进入一个组件/项目，就像MyApp.Common您可以在架构的任何其他项目/层（UI、逻辑、DAL 等）中安全地引用它们一样。可以这么说，这允许应用程序的所有层“说同一种语言”。

我对这种架构风格（不是 MVC，但共享一些概念）进行了适当的编写，在这里：https ://morphological.wordpress.com/2011/08/29/5-layer-architecture/

于 2017-07-14T02:55:15.433 回答