n 层架构 - BLL、DAL 和接口.什么是最佳实践? [英] n-layered architecture - BLL, DAL and interfaces. What is best practice?

问题描述

我有一个关于 n 层架构的问题.在问这个问题之前，我想了很久，因为这里已经有很多类似的问题了……但是，在看了一天半之后，我仍然不确定.各种看似相似的术语和不同的方法让我感到困惑.

I have a question regarding n-layer architecture. I thought long and hard before asking this question as there's a lot of similar questions here already... however, after literally a day and a half looking at it and reading these other answers I'm still unsure. The variety of seemingly similar terminology and different approaches has me confused.

如果我在不同的类库中有一个 BLL 和一个 DAL，那么在 BLL 和 DAL 之间进行通信的一种方法是利用一个接口，有点像在 BLL 和 DAL 都引用的另一个单独的 DLL 中定义的 DTO.BLL 中的域模型实体将实现此接口，DAL 中的任何 ORM 生成对象也将实现此接口.为了保存我的业务实体，我可以将它们传递给 DAL，后者会很好地接受它们，因为它们实现了共享接口.我还可以将对象传递回实现此接口的 BLL.这似乎是合理的，因为 BLL 和 DAL 只需要了解基本接口，而不是彼此的具体实现.

If I had a BLL and a DAL in different class libraries, one way to communicate between the BLL and DAL would be to utilise an interface, kind of like a DTO defined in another separate DLL that was referenced by both BLL and DAL. My domain model entities in the BLL would implement this interface and so would any ORM generated objects in the DAL. To save my business entities I could then pass them to the DAL which would accept them fine because they implement the shared interface. I could also pass objects back to the BLL that implement this interface. This seems reasonable as both BLL and DAL then only need to be aware of the basic interface, not each others concrete implementation.

我的问题是在另一侧创建对象的最佳方法是什么?例如，如果我在 BLL 中有一个实现 IPerson 的 Person 对象，以及一个 PersonDataObject 或同样实现 IPerson 的 DLL 中的任何对象，我将 Person 传递给 DAL 中采用 IPerson 参数的方法，然后在 DAL 中我'd 必须重建一个 PersonDataObject 才能持久化.这是最好的方法吗?

My question is what is what's the best method for creating the object on the other side? For example if I had a Person object in the BLL that implemented IPerson, and a PersonDataObject or whatever in the DLL that also implements IPerson, I pass Person to a method in the DAL which takes a parameter of IPerson, then in the DAL I'd have to reconstruct a PersonDataObject to persist. Is this even the best method?

抱歉，我可能没有完全解释清楚，因为我很困惑.非常感谢虚拟回答的最佳实践.

Sorry I probably haven't explained this all too well as I'm pretty confused. A best practice for dummies answer would be much appreciated.

推荐答案

一般来说，BLL 中的对象会使用接口——而不是实现它们:

Generally speaking, objects in the BLL will consume the interfaces - not implement them:

例如，如果我有一个 Person 对象在实现 IPerson 的 BLL 中，和一个 PersonDataObject 或任何也实现 IPerson 的 DLL

For example if I had a Person object in the BLL that implemented IPerson, and a PersonDataObject or whatever in the DLL that also implements IPerson

以Person"为例:考虑与一个人相关的不同数据操作(获取单个人的所有数据、多个人的浅层数据的集合、CRUD 操作、搜索等)——然后按照逻辑分组设计接口(请参阅接口分离原则).

Taking a "Person" as an example: think about the different data operations associated with a person (Getting all the data for a single person, a collection of shallow data for many persons, CRUD operations, searching, etc) - then design interfaces along logical groupings (see the Interface Segeragtion Principle).

接口可能代表以 BL 为中心的角度的操作 - 或基于服务"的角度.

The interfaces might represent operations from a BL centered perspective - or a "service" based one.

无论如何，要回答您的具体问题...

Anyway, to answer your specific question...

我在通用程序集中定义了 DTO 的等效项，数据接口也在单独的程序集中定义 - 所以我有 4 个程序集:BL、数据访问接口定义、接口实现和通用；所有程序集都引用通用程序集.

I define my equivalent of DTO's in a Common assembly, and the Data Interface in a separate one as well - so I have 4 assemblies: BL, Data Access Inteface definition, the Interface Implementation and Common; all assemblies reference the common one.

我在 C#.Net 中工作，我将 DTO 定义为结构(但您可以使用类)；并且这些属性的所有属性都是只读的 - 您可以在构造函数中将数据输入到它们中 - 这样 DTO 就实际上是愚蠢的"信息信封.

I'm working in C#.Net, I define the DTOs as structs (but you could use classes); and all the properties of these are readonly - you feed data into them in the constructor - this way the DTO's are effectly 'dumb' envelopes of information.

这篇关于n 层架构 - BLL、DAL 和接口.什么是最佳实践?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！