Картирование сущностей для nHIbernate Fluenty - PullRequest
Новая
       7

Картирование сущностей для nHIbernate Fluenty

0 голосов
/ 29 февраля 2012

У меня возникла небольшая проблема, когда я оборачиваюсь вокруг задачи или больше, поэтому лучший способ сделать это -

Взять пример проекта:

  • UI
  • ДАННЫЕ (сборка)
  • ОБСЛУЖИВАНИЕ (сборки), построенные на ДАННЫХ

Поместить ли все сопоставления в сборку ДАННЫХ или отделить ихв сервисные сборки?Или я должен / могу ли я вообще избавиться от сборки DATA?

Этот вопрос связан с наличием статического вспомогательного класса nHibernate либо в сборке DATA, либо в сборке UTILITY, на которую затем ссылаются сборки SERVICE и т. Д.

Project Reference direction

UI> DATA / UTILITY

DATA / UTILITY

UI> SERVICES

Я просто делаю это болеесложный или делает это неправильно / правильно?

Примечание:

Я упомянул Fluent, поскольку я знаю, что вы можете использовать config.xml для ссылки на сборки для сопоставления. Я не совсем уверен, как это сделатьэто с Fluent без фактической ссылки на сборки проекта - что приводит меня к циклической ссылке.

1 Ответ

0 голосов
/ 29 февраля 2012

Если вы хотите отделить код сопоставления от определений ваших объектов (ваших данных), вам нужна дополнительная сборка, сборка «слоя доступа к данным», которая ссылается на вашу сборку данных и содержит проблемы доступа к данным (например Сопоставления). Таким образом, ваша сборка DATA просто содержит ваши POCO и знает знание постоянства. Ваша сборка доступа к данным ссылается на вашу сборку DATA и обладает знаниями о постоянстве. Я бы не использовал ваши вспомогательные методы NHibernate из вашей сборки "UTILITY" и вместо этого поместил бы их в эту новую сборку "доступа к данным".

При всем этом, если вам не нужно отделять ваши данные от механизма их сохранения, вы можете просто сбросить все (отображения и вспомогательные функции) в сборку DATA.

...