EF N 层架构 [英] EF N-Tier Architecture

问题描述

简介

我们需要构建一个 n 层应用程序，因为我们希望在多个平台上共享我们的 BL，并且只编写我们的 DAL 一次.我已经对这个主题进行了一些研究.

We require to build a n-tier application, as we would like to share our BL over multiple platforms and only write our DAL once. I've already done some research on this subject.

可以在 Davide Piras 的帖子中阅读:MVC3 和实体框架每个 VS 解决方案必须至少有4层.到目前为止一切顺利.

As can be read here in Davide Piras's post: MVC3 and Entity Framework each VS solution must at least have 4 layers. So far so good.

他还表示，DAL 项目是唯一允许知道正在使用 EF 的项目.

He also states that the DAL project is the only project which is allowed to even know that EF is being used.

问题 1:

我假设接口"项目的接口是我的 EF 实体的一对一表示，我是否正确?另外，这些接口应该作为不同层之间的类型使用吗?

I'm assuming, that the interfaces of the 'Interfaces' project are a 1 on 1 representation of my EF entities, am i correct on this? Also, these interfaces should be used as types between the different layers?

问题 2:

MSDN 建议 DbContext 的生命周期应该是一个WebApps 的每个请求的上下文，WPF 或 WinForms 项目中的每个表单一个上下文.那么，如何在不向 GUI 层添加System.Data.Entity"的情况下实现这一点?

MSDN advices that the lifetime of a DbContext should be one context per request for WebApps, and one context per form in a WPF or WinForms project. So, how can i achieve this without adding 'System.Data.Entity' to my GUI layer?

提前谢谢！

推荐答案

首先请勿！！！在多个平台上共享您的 DAL.分享您使用 DAL 的 BL.只要您的 BL 代表您的应用程序要求的解决方案，您就不需要公开您的 DAL，请不要公开.此外，公开 DAL 的缺点是将更多的漏洞暴露给黑客，直接访问 DAL 可为您的 BL 中的业务逻辑、控制和验证提供 btpass 机制.

First of all DO NOT!!! share your DAL over multiple platform. Share your BL which uses DAL. As long as your BL represent solutions to your application requirements you do not need to expose your DAL and, please don't. Also exposing DAL has the disadvantage of exposing more vulnerabiilties to hackers and direct acces to DAL provides a btpass mechanism to your Business Logic, Controls and Validations in your BL.

答案 1:可能但不需要.考虑到 SOA，我建议使用 DTO.它们要么是实体，要么是多个和/或部分实体的更复杂的复合类.如果您使用实体，这将使您更灵活地通过 BL 提供信息(您可以通过一个方法调用一次发送多个数据部分)，并向第三方用户隐藏您的实体(也是 DB 结构)，从而提供更好的安全感.

Answer 1: Possibly but not need to. Thinking with SOA in mind I suggest to use DTOs. Either they are entities or more complex, composite classes of several and/or partial entities. If you use entities this gives you more flexibility to provide information via BL (you can send several portions of data at once by one method call) and hides youe entity (also DB structure) from third party users providing a better sense of security.

答案 2:再一次，考虑到 SOA，不要根据您的用户界面构建您的 BL/服务方法.BL(顾名思义)根据工作如何完成"而不是用户在屏幕上如何完成工作"提供数据.如果您尝试从 GUI 管理数据，您也将开始违反 N 层架构.请勿！！！使用 DAL 之外的任何数据特定类和/或方法.这将是分层的真正用途.

Answer 2: Again, thinking with SOA in mind, do not construct your BL/Service methods according to your User Interface. BL (as the name implies) provides data according to "how the work is done" not "how the work is done by the user on the screen". And if you try to manage your data from GUI you will also start to violate N-tier architecture. DO NOT!!! use any data spesific class and/or methods outside of DAL. This will be the true use of layering.

问候.

这篇关于EF N 层架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！