正分层架构 - 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之间进行通信的一种方式是利用一个接口，有点像在另一个单独的DLL中定义的DTO，是由两个BLL和DAL引用。在BLL我的域模型实体将实现此接口等任何会产生ORM在DAL对象。为了节省我的业务实体然后我可以将它们传递到其中会接受他们的罚款，因为他们实现了共享接口的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.

我的问题是什么是什么是对的另一边创建对象的最佳方法？例如，如果我在这实现IPerson的BLL一个Person对象和PersonDataObject或什么的也实现IPerson的DLL，我通过人在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?

对不起，我可能没有解释这一切太清楚，因为我是pretty困惑。傻瓜最佳做法的答案是多少AP preciated。

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

以人为例：想想有一个人（获得的所有数据的单身人士，浅数据的许多人，CRUD操作，搜索等的集合）相关联的不同的数据业务 - 再沿着逻辑组设计接口（请参见接口Segeragtion原则）。

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中心的观点重新present操作 - 或基于一个服务

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

总之，要回答你的具体问题...

Anyway, to answer your specific question...

我定义我的DTO相当于公司的一个共同的组件，并在单独的一个数据接口，以及 - 所以我有4个组件：BL，数据访问Inteface定义，接口的实现和通用;所有程序集引用常见的一种。

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的是effectly信息'哑巴'信封

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.

这篇关于正分层架构 - BLL，DAL和接口。什么是最好的做法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！