Assembly, Namespace, DAL;Какие классы принадлежат где?

Question

Я хотел бы понять несколько основ о сборках и пространствах имен.Я воспроизвел учебник NHibernate, и все работает отлично.Но я не уверен, согласен ли я с тем, какие уроки идут куда.Итак, посмотрите на прикрепленное изображение Solution Explorer ..

Домен и Репозитории (с классами в папках) - это пространства имен .И здесь оба находятся в ... DAL сборке.

1. Есть ли логическая причина, чтобы положить его туда? Продукт относится к классу POCO .Разве это не должно более естественно принадлежать вне сборки DAL?
2. Правильно ли поместить IProductRepository в пространство имен Domain ?И если бы вы предложили переместить классы POCO, вы бы также переместили IProductRepository?
3. Что бы мне нужно было сделать, если бы я хотел сделать DAL пригодным для использования в C # и VB.NET проектах?

Answer 1

Есть ли логическая причина, чтобы поставить его там? Продукт класса POCO. Не должно ли это более естественно принадлежать вне сборки DAL?

Аргумент за включение класса POCO в реализацию постоянства заключается в упрощении развертывания и сокращении общего количества необходимых сборок.

Это не значит, что я согласен с практикой.

Лучше и, возможно, даже более общепринятым, помещать определения доменных объектов в одну сборку и реализации, которые зависят от технологии персистентности в другой.

Клиенты могут затем ссылаться на сборку определений объектов домена без привязки к стратегии реализации.

Правильно ли поставить IProductRepository в Домене Пространство имен? И если вы предложите переехать классы POCO, вы также переехали бы IProductRepository?

Да, правильно, чтобы определение Репозитория находилось в Домене.

Репозитории являются концепцией домена, они не являются общими - по крайней мере, не интерфейс, который они предоставляют (реализации могут на самом деле быть общими). ​​

Интерфейсы для репозитория должны соответствовать определениям для сущностей (являются ли они интерфейсами POCO или просто интерфейсами) и со всеми другими объектами домена.

Что бы мне нужно было сделать, если бы я хотел сделать DAL пригодным для использования как C #, так и Проекты VB.NET?

Ничего особенного. Вы можете ссылаться на сборку из C # или VB.Net, независимо от того, были ли сборки DAL и / или Domain записаны в C # или VB.Net. Это большое преимущество .Net в целом, и оно сделано намеренно и конструктивно.

Answer 2

Обычно я бы помещал POCO в их собственную библиотеку, что-то вроде MyProject.Model или «Domain», как вы это называете.Причина в том, что я мог бы захотеть использовать их и вне DAL, где-то выше в пищевой цепи, не ссылаясь на сборку DAL.Например, я мог бы сопоставить .DataAccess с проектом .Business, который будет возвращать те же объекты .Model (Domain).Обычно мои репозитории живут, например, в MyProject.DataAccess.Repositories.Вы должны иметь возможность ссылаться на сборку .NET (независимо от того, является ли она C # или VB.NET) из любого проекта без проблем.