c# - 三层架构问题

Question

我有一个具有三层架构的 ASP.NET 应用程序：

• 表示层：ASP.NET

• 业务层：C# 库。

• 
  数据访问层：带有ADO.Net Entity Framework 对象的 C# 库。

业务层上的某些方法会返回 ADO.NET 实体对象，但是，数据访问层在表示层不可见，我不能这样做。

我的问题是：在设计视图中，在表示层中公开实体对象是否正确？我想我只需要将数据层库与 ASP.NET 应用程序链接起来。

谢谢！

Answer 1

让您的实体对象在您的表示层中可供使用和消费是绝对可取的。这就是所有工作的目的。

• 将对象集合绑定到网格/列表视图/下拉列表
• 将单个对象（即客户）溅到表单上以进行读取/更新/删除

到目前为止，这使您的生活更轻松。否则，您必须在您的演示层和业务层之间的字符串之后的双倍之后在 int 之后传递字符串。

这些可能是实体对象，甚至是您自己的从实体对象中提取的 POCO 对象。

我什至会说你的实体应该在他们自己的程序集中与 DAL 分开。

Answer 2

我认为不，不是，最好的方法是将数据类与行为分开，并仅在表示级别引用数据类。我认为使用 WCF 的好方法请参阅此链接

Answer 3

我建议您研究视图对象的概念......或数据传输对象（DTO）。您可能会考虑使用 AutoMapper 之类的工具或类似工具，该工具将从您的实体中创建视图特定的域对象。通常，您的屏幕可能需要一个实体来执行其工作。但通常情况下，您需要传递几个不同的实体。在这种情况下，您最好创建一个包含所有这些实体的 DTO。通过这样做，您在表示层和业务层之间添加了一层分离。通常情况下，您的实体拥有的权力比您希望向表示层公开的权力要大。而且……反之亦然。通常，您可能需要根据业务层中标记的某些验证将一些 UI 消息发送到表示层。与其让你的 ui 比它需要的更复杂（通过传入你的完整实体），你只能以 DTO 的形式传入 UI 需要的东西。此外，您的业务对象永远不需要关心特定于表示层的任何事情。我建议您不要直接将数据绑定到任何数据访问层。从技术上讲，您的表示层应该尽可能少地了解您的业务层。在 MVP 或 MVC 的情况下，通过这种额外的分离来断开前端和后端的连接很容易实现！我建议您不要直接将数据绑定到任何数据访问层。从技术上讲，您的表示层应该尽可能少地了解您的业务层。在 MVP 或 MVC 的情况下，通过这种额外的分离来断开前端和后端的连接很容易实现！我建议您不要直接将数据绑定到任何数据访问层。从技术上讲，您的表示层应该尽可能少地了解您的业务层。在 MVP 或 MVC 的情况下，通过这种额外的分离来断开前端和后端的连接很容易实现！

Answer 4

请参阅监督控制器 和被动视图

如果您通过实体，您实际上是在监督控制器。否则你就是被动视图。

监督控制器的工作量较少，但可测试性较差。监督控制器还说数据绑定是可以的。被动视图是可测试的，但还有很多工作要做。没有数据绑定。很多楼盘。

通常我坚持使用监督控制器。您通常不需要那种级别的可测试性，而且不值得额外的麻烦。