Использование ORM с базой данных, которая не имеет определенных отношений?

Question

Рассмотрим базу данных (MSSQL 2005), состоящую из более 100 таблиц, в которых в определенной степени определены первичные ключи. Между таблицами существуют «отношения», однако они не применяются с ограничениями внешнего ключа.

Рассмотрим следующий упрощенный пример типичных типов таблиц, с которыми я имею дело. Четкие отношения между таблицами User и City и Province. Тем не менее, они являются ключевыми проблемами несовместимых типов данных в таблицах и соглашений об именах.

User:
    UserRowId [int] PK
    Name [varchar(50)]
    CityId [smallint]
    ProvinceRowId [bigint]

City:
    CityRowId [bigint] PK
    CityDescription [varchar(100)]

Province:
    ProvinceId [int] PK
    ProvinceDesc [varchar(50)]

Я рассматриваю переписывание приложения (в ASP.net MVC), которое использует этот источник данных, так как аналогично по дизайну для витрины MVC. Однако я прохожу этап проверки концепции, и это один из камней преткновения, с которым я столкнулся.

1. Какие у меня варианты с точки зрения выбора ORM, которые можно легко использовать и почему?

2. Должен ли я даже рассматривать ORM? (Причина, по которой я спрашиваю это, состоит в том, что большинство объяснений и учебных пособий работают с относительно аккуратно спроектированными существующими или вновь созданными базами данных по сравнению с моими. Таким образом, мне очень трудно пытаться найти путь для решения этой проблемы) *

3. Существует огромное количество существующих SQL-запросов. Может ли datamappper (например, IBatis.net) быть более подходящим, поскольку мы могли бы легко изменить их для работы и повторно использовать уже сделанные инвестиции?

Я нашел этот вопрос на SO, который указывает мне, что ORM можно использовать - однако у меня сложилось впечатление, что это вопрос картографирования?

Примечание: на данный момент объектная модель не четко определена, поскольку ее не существовало. Существующая система в значительной степени выполняла почти все в SQL или состояла из слишком сложных и многочисленных запросов для полной функциональности. Я в значительной степени новичок и у меня нет опыта работы с ORM и MVC - так что я нахожусь на этой удивительной кривой обучения.

Answer 1

Я согласен с Беном.

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

Работа? Очень быстро избавьтесь от всего этого SQL и замените его абстракцией. Какой ORM? Я обнаружил, что использование существующего ORM для ретроспективного размещения над плохой базой данных (большинство баз данных действительно) является плохой новостью. Я думаю, что это проблема с ORM, они перемещают проблемы базы данных / хранилища ближе к приложению ... не дальше.

Мое решение: Светоотражающий ORM, который использовал только существующее состояние базы данных, чтобы выяснить, что происходит. Все операции выбора, вставки, обновления и неиспользуемые просмотры / хранимые процедуры маскируют грязную базу данных. Он работает на основе API linq-esque, просто перепишите мрачный SQL. Сварилось около 100kloc операторов SQL до менее 2kloc.

профи : Я могу постепенно перенести базу данных в лучшую структуру за представлениями и действиями. ИМХО, именно так должны быть организованы все базы данных , полностью использующие абстракцию, предоставляемую SP и представлениями. Я никогда не хочу видеть один оператор SQL (или ORM, маскирующийся под SQL) непосредственно против таблицы.

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

хак, без сомнения , но он работает так хорошо, что я использую его в проектах, где я могу проектировать базу данных с нуля;)

Answer 2

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

У нас была роскошь выбора технологии, и мы выбрали внешний интерфейс MVC2 (не имеет отношения к вашему вопросу), и у нас было 2 разработчика: одна попытка смоделировать с помощью NHibernate, другая с использованием Entity Framework 4.

Спешу добавить, что у нас было четкое представление о том, что мы хотели от нашей модели предметной области, и сначала смоделировали это (не желая быть ограниченным базой данных), поэтому наш объект «Пользователь» с точки зрения схемы фактически охватывая 5 таблиц, мы инкапсулировали большую часть бизнес-логики, чтобы модель предметной области не была анемичной, и как только мы были довольны нашим объектом User, мы начали процесс попытки подключить ORM.

Я могу без колебаний сказать, что в обоих случаях (NH и EF4) компромиссы, которые нам пришлось сделать с нашей моделью, чтобы продемонстрировать реализацию, были феноменальными. Я приведу вам примеры из EF4, так как это тот, в котором я больше всего участвовал, другие могут связать их с другими ORM.

частные сеттеры

Нет - не в твоей жизни с EF4. Ваши свойства должны быть публичными. Существуют обходные пути (например, создание оболочек для свойств, поступающих из вашей БД)

перечисления

Опять же, нет - была концепция обертки и «отображение», чтобы попытаться получить доступ к базе данных int из типов enum моделей.

результаты

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

куда мы пошли после этого?

Linq to SQL с нашим собственным отображающим слоем. И мы никогда не оглядывались назад - абсолютно фантастически - мы сами написали слой отображения, который переносит объект Dto на слой Dal и отображает его (как мы его указываем) в нашу модель Домена.

Удачи в любом исследовании ORM, я бы, конечно, повторно исследовал бы их, если бы у меня была приличная схема, на которой они основывались, но сейчас, с ужасной схемой, было проще свернуть нашу собственную.

Ура, Махровый

Answer 3

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