Распространено ли свободное отображение в одном проекте с объектами?

Question

За последние два года мои коллеги, блоги и книги научили меня, что базовая структура проекта для достойного решения должна быть разделена на Presentation, Data, Entities как отдельные проекты. (Больше в зависимости от того, сколько слоев вам нужно для определенных вещей. Например, в некоторых случаях может быть переходный слой)

Но при использовании Fluent nHibernate я постоянно перестраиваю одну и ту же структуру каталогов между двумя различными проектами Visual Studio - и для какой цели? Мне сказали, что это связано с идеей разделения интересов и тем, что слои можно поменять местами ... но серьезно, действительно ли люди часто меняют целые слои доступа к данным?

Является ли это стандартным или даже ... не смеющимся на практике, просто объединить ваши Fluent Mappings в один и тот же проект, в котором находятся сущности, для которых они сопоставлены? Есть ли логическая причина, почему я не должен этого делать? Я новичок во всех отношениях, и любое мнение очень ценится.

Answer 1

Один момент заключается в том, что вы не всегда хотите или можете предоставлять доступ к данным (сопоставления).В частности, обычно есть только один компонент, который использует уровень доступа к данным, и многие другие части, которые используют только API классов данных и никогда не знают о доступе к данным.В моем текущем проекте клиентское приложение работает в среде, которая не может обрабатывать ссылки на NHibernate, что делает невозможным доступ к данным.Но клиент использует классы данных.В другом проекте мои (автоматически сгенерированные) классы данных использовались на нескольких языках программирования и платформах.Гораздо последовательнее было всегда иметь их в отдельном модуле / сборке / проекте / что угодно, иметь согласованный API независимо от используемой платформы.Только сервер использовал доступ к данным.

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

Кроме того,Исходя из моего опыта, нередко меняются местами слои доступа к данным.

Кстати, почему вам так неприятно отделять сущности от классов данных?Да, с сегодняшними все еще несовершенными инструментами программирования вы снова и снова будете повторять те же самые практики (надеюсь, не повторяя код), но по уважительной причине.

Answer 2

Хотя люди не часто меняют свои слои доступа к данным, это не является веской причиной, чтобы затруднять это.Если в следующем году появится еще один лучший ORM, вы можете просто заменить сопоставления Fluent NHibernate на сопоставления для нового ORM в своем проекте доступа к данным, не внося никаких изменений в логику клиента.Фактически, вы могли бы даже предоставить возможность использовать любой из них во время выполнения.

Другая причина перемещения отображения данных за пределы объектов домена состоит в том, чтобы способствовать повторному использованию объектов.Допустим, вы решили повторно использовать ваши доменные объекты (те, которые вы отображаете с помощью Fluent NHibernate сейчас) в другом проекте, которому не нужно хранить их в базе данных, например, в клиентском приложении.Вы бы не хотели, чтобы у вашего клиентского приложения была зависимость