Разработка многоуровневого приложения с NHibernate и базой данных, изменяющей контекст - PullRequest
Новая
       45

Разработка многоуровневого приложения с NHibernate и базой данных, изменяющей контекст

2 голосов
/ 01 октября 2010

Я разрабатываю приложение на C #

  • Презентация (веб-сайт + гибкие приложения)
  • Бизнес-логический уровень (может быть WCF для поддержки мульти-клиентских платформ)
  • Уровень доступа к данным (с NHibernate)

Мы собираемся интегрировать наше решение во многие предсуществующие клиентские среды баз данных, и мы хотели бы использовать NHibernate в DAL. Мой коллега отметил, что генерация классов из клиентской БД (например, User или Image) с помощью NHibernate вызовет БЛЛ взорвать нам в лицо при каждом изменении БД! Итак, вопрос в том, как мы можем предотвратить это? Мы думаем о создании бизнес-объектов и отображении объектов NHibernate на эти BO (гум, это делает их DTO?) С помощью AutoMapper и предотвращает влияние изменений DAL на BLL. Так ли это?

Спасибо!

РЕДАКТИРОВАТЬ:

Чтобы лучше понять, чего мы пытаемся достичь, вам может понадобиться контекст: Мы создаем приложение для хранения и обмена фотографиями во Flex для внешнего интерфейса и C # для внутреннего интерфейса, в основном для нашей компании, поэтому мы обрабатываем все аспекты кода и БД.

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

Даже если бы это было возможно (например, пользовательская таблица может быть изменена из-за меньшего количества строк), мы задаемся вопросом, как обрабатывать изменения структуры таблицы, не влияя на все наше решение каждый раз, когда нам приходится интегрироваться в базу данных уровня , от BLL до клиентского приложения во Flex!

Ответы [ 2 ]

2 голосов
/ 02 октября 2010

По моему опыту, ваши бизнес-объекты (доменные объекты AKA) должны быть смоделированы в ОО, чтобы представлять ваши реальные бизнес-объекты и ваши таблицы в 3-й нормальной форме (это может измениться в зависимости от того, какой у вас дизайн после скорости и размера файла)

NHibernate должен отображаться между вашими BO и таблицами, используя его файлы сопоставления.

теперь у вас есть законные случаи:

  • Вам нужно добавить / удалить столбец,мы решили удалить addressline4, это будет отражать изменение в вашем объекте адреса, это нормально.
  • Вы перемещаете столбец в лучшее место, наш объект Client содержит заметки, которые в настоящее время хранятся в таблице Contract_Extra, котораябудет перемещен в таблицу клиентов.перемещение столбца в лучшее место будет влиять только на файл сопоставления, в этом случае

Я сомневаюсь, что есть общие рассуждения, однако я надеюсь, что примеры заставят вас задуматься об этом

Я не пробовал NH для нескольких Db, также каждая база данных должна иметь свой собственный сервис поверх ?

вот несколько ссылок

  • Multi tableentites
  • PoEAA <- посмотрите наследование одиночной таблицы, наследование таблицы классов и другое </li>

Надеюсь, это поможет

0 голосов
/ 01 октября 2010

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

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

Это всего лишь некоторые мысли. Более опытные пользователи с NHibernate, вероятно, лучше поймут вашу ситуацию.

...