我的 3 层（n 层）架构是好的设计吗？答案

【问题标题】：Is my 3-tier (n-tier) architecture good design?我的 3 层（n 层）架构是好的设计吗？
【发布时间】：2010-08-15 05:21:58
【问题描述】：

我正在使用 ASP.NET MVC 和实体框架开发一个中型 ASP.NET 项目。我通过设置 3 个 Visual Studio 项目并相应地引用它们开发了一个 3 层系统：

Presentation -- 这是我的 MVC 项目，包含所有视图和控制器。我将模型文件夹从该项目中完全删除，因为我将其移至 BO 项目（见下文）
Business Objects (BO) -- 该项目包含应用程序的“肉”，是应用程序的真正核心所在。在这里，定义的对象代表我试图在代码中建模的事物（用户、设施、约会等）。
数据访问 (DA) - 到目前为止，这个项目都是实体框架。

我遇到的“问题”是我在 BO 中进行了大量手动的一对一映射。例如，当调用 User.load() 时，我从 EF 加载用户，然后将 EF 结果中的一些参数（名字、姓氏、用户名、活动等）映射到对象上的参数。

我认为这有好有坏。很好：它将 EF 与项目断开连接，因此如果我需要使用另一个数据存储，我不仅仅与 EF 相关联。不好：这需要更多时间，因为我必须设置每个参数并通过实现我自己的更改跟踪在 Add()、Update() 等上仔细处理它们。

您如何看待这种方法？

【问题讨论】：

标签： asp.net-mvc entity-framework n-tier-architecture

【解决方案1】：

它将 EF 与项目断开连接

确实不错。

我在 BO 中做了很多手动的一对一映射

我建议你看看AutoMapper。

我发现 Manning 的 ASP.NET MVC in Action 一书非常好。最近发布的第二个版本也包含一个关于 AutoMapper 的小章节。它不在免费的示例章节中，但您可能想查看源代码（当然也可以购买这本书）。

【讨论】：

【解决方案2】：

如果您使用的是 .Net 4.0，那么您绝对应该考虑创建和使用 POCO 实体而不是 EntityObject，这不仅会给您带来持久性无知（您已经提到过），而且您在工作后不需要任何 Mapper在包括您的数据访问在内的所有层中使用 POCO（普通旧 CLR 对象）。如果您还没有使用过 EF 和 POCO，那么这将是一个好的开始： http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx

如果您使用的是 .Net 3.5 SP1 并且无法升级到 4.0，那么就像正确提到的 XIII 一样，AutoMapper 将自动执行您的映射过程，或者您可以提出自己的 AutoMapper，这只不过是一个简单的反射代码。

【讨论】：