Советы по макету проекта nhibernate, хотите разместить связанный с nhibernate код в собственном проекте

Question

Я создаю приложение asp.net mvc, проекты, которые у меня есть в моем решении до сих пор:

Solution.PROJECT1
PROJECT1.Web
PROJECT1  
PROJECT1.Tests
PROJECT1.Data
PROJECT1.Data.Tests

Итак, у PROJECT1.Data есть весь мой связанный с nhibernate код: сущности, сопоставления и репозитории.

PROJECT1 будет иметь мой сервисный уровень и будет ссылаться на проект nhibernate. Интернет будет ссылаться только на сервисный уровень.

Мой вопрос таков: что если у меня есть несколько объектов, которые мне нужно поместить в PROJECT1.Data и PROJECT1?

И примером этого является класс Logger, который я хотел создать.

Я хочу избежать ссылок на рекурсивные сборки и т. Д.

Должен ли я создать другой проект с этими классами?

Answer 1

В дополнение к тому, что @Davide сказал:

Я бы рассмотрел возможность извлечения сущностей в их собственный проект, который НЕ будет ссылаться на данные или nHibernate.
Таким образом вы убедитесь, что ваша модель предметной области не зависит от представления данных.

Также я думаю, что желательно, чтобы уровень пользовательского интерфейса взаимодействовал не с объектами домена, а с DTO (или объектами представления).
Это еще больше уменьшит зависимость между бизнес-логикой и логикой пользовательского интерфейса, а также упростит отправку клиенту только того, что ему нужно (например, объект User может содержать поля, такие как PasswordHash, Salt, LastUpdated. Но вы хотите отображать только имя пользователя и дату последнего входа в систему. Проще, если вы используете DTO, чтобы создать тот, который содержит только то, что вам нужно, и ваш сервисный уровень возвращает , что .)

Answer 2

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

У меня также была бы отдельная пара проектов .Interfaces и .Entities, часто случается, что пользовательский интерфейс должен знать сущность только по его интерфейсу, поэтому пользовательский интерфейс не должен ссылаться на сущности, а ваш сервисный уровень делает.

Я бы добавил пользовательские классы исключений, которые вам могут понадобиться, в интерфейсах, общих или сущностях. Общее, вероятно, лучше, но оно меньше двух других, поэтому зависит, нужен ли вам уже один из этих интерфейсов.