Устаревшее сопоставление базы данных MySQL с хорошим .NET ORM для миграции системы - PullRequest
1 голос
/ 29 февраля 2012

Это довольно долго, но я очень ценю ваши мысли и предложения.

Мы заняты восстановлением устаревшей системы, написанной на PHP и MySQL, и заменой ее компонентов ASP.MVC на C # и SQL Server. Устаревшая архитектура оставляет желать лучшего много , и существует серьезная проблема с кодом спагетти, отсутствием ссылочной целостности в БД, неиспользуемым полем кода и базы данных и просто плохим кодированием.

Как бы мне ни хотелось, мы не можем просто вырвать весь старый код и заменить его. Компания должна оставаться функциональной в процессе разработки, поэтому нам нужно будет создавать новые функциональные возможности, используя старые базы данных, чтобы гарантировать постоянную точность их данных. Уровень точности данных не в режиме реального времени, но если бы у нас было 2 системы, они должны были бы быть синхронизированы в 100% случаев. Старая система использует 6 разных баз данных MySQL, все на одном сервере под управлением Linux. Мы будем использовать Windows 2008 R2 на новом сервере для новой системы, и мы планируем использовать последнюю версию SQL Server.

Проблема, которую мне нужно решить, заключается в следующем: мне нужно каким-то образом отобразить все эти базы данных в консолидированную модель, которую мы можем использовать через C # для разработки новой системы. После того, как мы переместили всю функциональность на C #, нам нужно перенести данные в БД, соответствующую нашей модели кода. Эта БД будет работать на SQL Server. Я пока не слишком беспокоюсь о миграции; Моя текущая проблема - найти инструмент ORM, который позволит мне отобразить эти 6 баз данных MySQL в единую, хорошо спланированную и спроектированную модель, которую мы можем использовать для новой разработки.

В новой модели могут быть дополнительные поля, которые нам придется хранить в новой базе данных MySQL, пока мы не перенесем данные на каком-то этапе, поэтому ORM должен легко поддерживать объекты, которые охватывают несколько таблиц и баз данных.

Возможно ли то, что я пытаюсь сделать? Это жизнеспособно с точки зрения усилий? Есть ли ORM, который может сделать все это? и как еще можно поддерживать работоспособность компании при активной разработке системы?

Я просмотрел следующие параметры ORM:

  • SubSonic (отлично, но я думаю, что слишком легкий для того, что мы пытаемся)
  • Entity Framework (похоже, я мог бы использовать это, если я использую очень грязные модели с тоннами хранимых процедур для вставок, обновлений и удалений)
  • NHibernate (клиент не хочет, чтобы мы использовали это из-за плохого опыта в прошлом)
  • LLBLGen (кажется, что он может делать то, что нам нужно, но долгосрочная поддержка может быть проблемой для клиента)

Что-нибудь еще, на что я должен смотреть? Могу ли я попробовать другой подход?

Ответы [ 2 ]

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

Для Entity Framework: если вы готовы поддерживать один полный набор хранимых процедур со статическим интерфейсом (т. Е. С одной и той же подписью), вы можете реализовать их все в Transact-SQL на коробке SQL Server со связанными серверами (для MySQL farm).

Когда придет время, вы можете перенести данные в SQL Server и обновить свои хранимые процедуры.

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

SQL Server имеет тенденцию извлекать всю удаленную таблицу, когда вы выполняете запросы к связанному серверу, поэтому, если производительность представляет собой проблему, это может привести к тому, что все ваши хранимые процедуры будут обернуты вокруг OPENROWSET (см. Пример A для запуска запроса на удаленном сервере).

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

ORM не предназначены для решения вашей проблемы.Тем не менее, качественный ORM даст вам некоторый процент пути к решению.

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

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

...