我的3层（n层）架构是否设计良好？

Question

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

• 演示文稿 - 这是我的MVC项目，包含所有视图和控制器。当我将它移动到BO项目（见下文）
时，我完全从这个项目中删除了模型文件夹
• Business Objects（BO） - 此项目包含应用程序的“肉”，是应用程序的真正核心所在。在这里，定义的对象代表我试图在代码中建模的东西（用户，工具，约会等）。
• 数据访问（DA） - 此项目到目前为止都是实体框架。

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

我认为这是好事和坏事。好：它将EF与项目断开连接，所以如果我需要使用另一个数据存储，我不仅仅与EF绑定。不好：需要花费更多时间，因为我必须设置每个参数并通过实现我自己的更改跟踪在Add（），Update（）等上仔细处理它们。

您如何看待这种方法？

Answer 1

  

它将EF与项目

断开连接

这确实很好。

  

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

我建议你看看AutoMapper。

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

Answer 2

如果您使用的是.Net 4.0，那么您一定要考虑创建和使用POCO实体而不是EntityObject，它不仅可以为您提供Persistence Ignorance（您已经提到过），而且您工作之后也不需要任何Mapper在所有层中使用POCO（Plain Old CLR Object），包括您的数据访问。 如果您还没有使用EF＆amp; 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，它只不过是一个简单的反射代码。