Покрытие от наборов данных к хранимым процессам и современному ORM - PullRequest
Новая
       17

Покрытие от наборов данных к хранимым процессам и современному ORM

0 голосов
/ 07 мая 2009

Сколько усилий потребуется для миграции большой существующей кодовой базы со слоя доступа к данным на основе строго типизированного набора данных на DAL, управляемый хранимыми процессами и / или более современным пакетом ORM? Есть ли какой-нибудь блестящий инструмент, который автоматизирует часть этого процесса?

Текущая база кода имеет более 100+ наборов данных, отражающих базу данных sql (но не всегда была на 100% синхронизирована с изменениями в структуре БД). Сегодняшняя позиция такова, что сейчас было бы слишком много времени / усилий, чтобы измениться, но я сомневаюсь, сколько технического долга это оставляет нам, чтобы платить каждую неделю. Это не говоря уже о производительности в бэкэнде SQL наборов данных по сравнению с оптимизированным sproc.

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

1 Ответ

2 голосов
/ 07 мая 2009

Я бы сказал, что переход на ORM, такой как LINQ to SQL, будет намного менее трудоемким по сравнению со слоем DAL с хранимой процедурой. Несколько вещей, которые приходят мне в голову:

  • Ситуация 1 - если вы используете наборы набранных данных вне вашего DAL [в интерфейсе пользователя, BLL], тогда усилия наверняка будут высокими, потому что вам потребуется провести обширный анализ воздействия изменений и сделать меняется практически везде, где вы использовали свои набранные наборы данных.

  • Ситуация 2 - если вы используете свои типизированные наборы данных ТОЛЬКО без DAL и вашего пользовательского интерфейса, BLL не заботится о внутренней реализации DAL и не обращает внимания на типизированный набор данных, тогда это будет гораздо менее трудоемким. Вам нужно будет изменить только внутри слоя DAL.

  • Если вы находитесь в ситуации 2, то я думаю, что было бы определенно целесообразно перейти от типизированных наборов данных к ORM mapper.

  • Если вы намереваетесь использовать хранимый подход к DAL, то вы можете обратиться к www.mygenerationsoftware.com, чтобы автоматически сгенерировать свои процессы, чтобы уменьшить некоторые усилия, однако усилия все равно будут выше по сравнению с сопоставителем ORM. и другой недостаток может заключаться в том, что в вашей базе данных будет множество простых процедур вставки / обновления. мы обычно используем процы в основном для каскадных UPSERTS (обновление + вставка) или только для сложных вычислений и используем LINQ to SQL для базовой вставки, обновления, удаления.

надеюсь, это как-то поможет!

...