三层架构问题
我有一个具有三层架构的 ASP.NET 应用程序：
表示层：ASP.NET
业务层：C# 库。
数据访问层：C# 库
ADO.Net 实体框架对象。
业务层上的一些方法将返回 ADO.NET 实体对象，但是数据访问层在表示层上不可见，我无法这样做。
我的问题是：在设计视图上，在表示层中公开实体对象是否正确？ 我想我只需要将数据层库与 ASP.NET 应用程序链接起来。
谢谢你！
I have an ASP.NET app with a three layer architecture:
Presentation layer: ASP.NET
Bussiness Layer: C# library.
Data Access Layer: C# library with
ADO.Net Entity Framework objects.
Some methods on Bussiness layer would return ADO.NET entity objects but, data access layer is not visible at Presentation layer I can't do that.
My question is: On a design view, Is it correct to expose Entity Objects in the Presentation Layer? I think I only have to link Data Layer library with ASP.NET app.
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
绝对希望您的实体对象可以在表示层中使用和消耗。 这就是所有工作的目的。
这使您的生活变得更轻松。 否则，您必须在表示层和业务层之间传递字符串，再传递int，再传递double。
这些可能是 Entity 对象，甚至是您自己的从 Entity 对象中水化的 POCO 对象。
我什至会说你们的实体应该在他们自己的议会中，与 DAL 分开。
It's absolutely desirable to have your entity objects available for use and consumption in your presentation tier. That's what all the work is for.
This makes your life easier by far. Otherwise you'd have to pass string after int after double after string between your presentation and business layers.
These may be Entity objects or even your own POCO objects that were hydrated from the Entity objects.
I would even go so far as to say that your Entites should be in their own assembly separate from the DAL.
我建议您研究一下视图对象...或数据传输对象 (DTO) 的概念。 您可能会考虑使用 AutoMapper 或类似工具，它将从您的实体中创建视图特定的域对象。 一般来说，您可能拥有需要存在实体才能执行其工作的屏幕。 但通常情况下，您需要传递几个不同的实体。 在这种情况下，您最好创建一个包含所有这些实体的 DTO。 通过这样做，您可以在表示层和业务层之间添加一个分离层。 通常，您的实体拥有的功能超出了您想要向表示层公开的功能。 而且……反之亦然。 通常，您可能需要根据业务层中标记的某些验证将一些 UI 消息发送到表示层。 您只能以 DTO 的形式传入 UI 所需的内容，而不是让您的 ui 变得比需要的更复杂（通过传递完整的实体）。 此外，您的业务对象永远不需要关心表示层特定的任何内容。 我建议您不要直接将数据绑定到远至数据访问层的任何内容。 从技术上讲，您的表示层应该尽可能少地了解您的业务层。 在 MVP 或 MVC 的情况下，通过这种额外的分离来断开前端和后端，这很容易实现！
I suggest that you look into the concepts of View objects...or Data Transfer Objects (DTO). You might consider using a tool like AutoMapper or similar which will create a view specific domain object out of your entities. In general you may have screens that need an entity present to perform its work. But more often than not you will need to pass several different entities. In this case you are better off creating one DTO that contains all of these entities. By doing this you are adding a layer of separation between your presentation layer and your business layer. Often times your entities have more power than you might want to expose to your presentation layer. And...vice versa. Frequently you may need to get some UI messages out to the presentation layer based on some validation flagged in your business layer. Rather than make your ui more complex than it needs to be (by passing in your full entities) you can only pass in what the UI needs in the form of the DTO. Also, there is never a need for your business objects to care about anything specific to the presentation layer. I suggest that you not databind directly to anything as far back as the data access layer. Technically your presentation layer should know as little as possible about your business layer. In the case of MVP or MVC this is very easy to achieve by disconnecting the front end and the back end by way of this additional separation!
我认为不，不是，最好的方法是将数据类与行为分开，并仅引用表示级别的数据类。我认为使用 WCF 的好方法请参阅此 链接
I think no, it is not, the best way to do that is to separate data classes from behavior, and reference only data classes in presentation level.The good approach I think to use WCF see this link
请参阅监督控制者和被动视图
如果你传递了实体，那么你本质上就是监督控制器。 否则你就是被动观点。
监督控制器的工作量较少，但可测试性较差。 监督控制器也说数据绑定没问题。
被动视图是可测试的，但还有很多工作要做。 没有数据绑定。 很多属性。
通常我会坚持使用监督控制者。 您通常不需要那种级别的可测试性，也不值得为此付出额外的努力。
See Supervising Controller and Passive View
If you pass the Entity, you are essentially Supervising controller. Otherwise you are Passive View.
Supervising controller is less work, but less testable. Supervising Controller also says databinding is OK.
Passive view is testable but a LOT more work. No databinding. Lots of properties.
Typically I stick with Supervising Controller. You typically don't need that level of testability and it isn't worth the extra trouble.