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

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

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

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

Спасибо!

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

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

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

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

Источник

2 ответа

Решение

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

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

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

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

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

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

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

  • Multi Table Entites
  • PoEAA <- посмотреть наследование одной таблицы, наследование таблицы классов и другое

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

Источник

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

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

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

Источник
Другие вопросы по тегам