开发者

Assembly, Namespace, DAL; What classes belongs where?

开发者 https://www.devze.com 2023-02-07 04:34 出处:网络
I would like to understand a few basics about Assemblies and Namespaces. I\'ve reproduced an NHibernate tutorial, and everythin开发者_运维技巧g works fine. But I\'m not sure if I agree on what classes

I would like to understand a few basics about Assemblies and Namespaces. I've reproduced an NHibernate tutorial, and everythin开发者_运维技巧g works fine. But I'm not sure if I agree on what classes go where. So look at Solution Explorer image attached..

Domain and Repositories (with classes in folders) are namespaces. And here both are in the ...DAL assembly.

  1. Is there any logical reason to put it there? Product is a POCO class. Shouldn't that more naturally belong outside the DAL assembly?
  2. Is it correct to put IProductRepository in the Domain namespace? And if you suggest to move the POCO classes, would you also move the IProductRepository?
  3. What would I need to do if I wanted to make the DAL usable by both C# and VB.NET projects?

Assembly, Namespace, DAL; What classes belongs where?


Is there any logical reason to put it there? Product is a POCO class. Shouldn't that more naturally belong outside the DAL assembly?

The argument for putting the POCO class in with the persistence implementation is to simplify deployment and reduce the total number of needed assemblies.

That is not to say I agree with the practice.

It is a better practice, and perhaps even more conventional, to place the definitions of the domain objects in one assembly, and the implementations that depend on the persistence technology in another.

Clients can then reference the assembly of domain object definitions without being tied to the implementation strategy.

Is it correct to put IProductRepository in the Domain namespace? And if you suggest to move the POCO classes, would you also move the IProductRepository?

Yes, it is correct for the definition of a Repository to be in the Domain.

Repositories are a domain concept, they are not generic - at least not the interface they expose (the implementations may in fact be generic).

The interfaces for the Repository should live with the definitions for the Entities (whether they are POCO's or just interfaces) and with all other domain objects.

What would I need to do if I wanted to make the DAL usable by both C# and VB.NET projects?

Nothing special. You can reference the assembly from either C# or VB.Net, whether the DAL and/or Domain assemblies were written in C# or VB.Net. This is a large advantage of .Net as a whole and is quite intentional and by design.


Typically I would put the POCOs in their own library, something like MyProject.Model or "Domain" as you call it. The reason being is that I might want to use them outside of the DAL as well, somewhere higher on the food chain without referencing the DAL assembly. For example I might front the .DataAccess with a .Business project, which will return the same .Model (Domain) objects. Typically my repositories live in MyProject.DataAccess.Repositories for example. You should be able to reference a .NET assembly (no matter if it's C# or VB.NET) from any project without any problems.

0

精彩评论

暂无评论...
验证码 换一张
取 消