Я работаю в компании, которая использует только хранимые процедуры для всего доступа к данным, что очень раздражает, когда мы синхронизируем наши локальные базы данных, так как каждый коммит мы должны запускать новые процессы. Я использовал некоторые базовые ORM в прошлом, и я считаю, что опыт намного лучше и чище. Я хотел бы предложить менеджеру по разработке и остальным членам команды, что мы рассмотрим использование ORM некоторого вида для будущей разработки (остальная часть команды знакома только с хранимыми процедурами и никогда не использовала ничего другого). Текущая архитектура - .NET 3.5, написанная как .NET 1.1, с «богами», которые используют странную реализацию ActiveRecord и возвращают нетипизированные наборы данных, которые зациклены в файлах с выделенным кодом - классы работают примерно так:
class Foo {
public bool LoadFoo() {
bool blnResult = false;
if (this.FooID == 0) {
throw new Exception("FooID must be set before calling this method.");
}
DataSet ds = // ... call to Sproc
if (ds.Tables[0].Rows.Count > 0) {
foo.FooName = ds.Tables[0].Rows[0]["FooName"].ToString();
// other properties set
blnResult = true;
}
return blnResult;
}
}
// Consumer
Foo foo = new Foo();
foo.FooID = 1234;
foo.LoadFoo();
// do stuff with foo...Практически нет применения каких-либо шаблонов дизайна. Там нет никаких тестов вообще (никто больше не знает, как писать модульные тесты, и тестирование выполняется через загрузку веб-сайта вручную и поиск по нему). Просматривая нашу базу данных, мы имеем: 199 таблиц, 13 представлений, колоссальные 926 хранимых процедур и 93 функции. Около 30 или около того таблиц используются для пакетных заданий или внешних вещей, остальные используются в нашем основном приложении.
Стоит ли вообще придерживаться другого подхода в этом сценарии? Я говорю о продвижении вперед только потому, что нам не разрешается рефакторинг существующего кода, так как «он работает», поэтому мы не можем изменить существующие классы для использования ORM, но я не знаю, как часто мы добавляем новые модули вместо добавление / исправление текущих модулей, поэтому я не уверен, является ли ORM правильным подходом (слишком много вложено в хранимые процедуры и наборы данных). Если это правильный выбор, как мне представить кейс для его использования? Вдобавок ко всему, единственное преимущество, которое я могу придумать, это иметь более чистый код (хотя это может и не быть, поскольку текущая архитектура не ' t построены с учетом ORM, поэтому в основном мы будем включать ORMs присяжных в будущие модули, но старые по-прежнему будут использовать наборы данных) и меньше хлопот, чтобы помнить, какие скрипты процедур были запущены и какие должны быть запущены, и т.д., но это все, и я не знаю, насколько убедительным будет такой аргумент. Ремонтопригодность - это еще одна проблема, но кажется, что никто, кроме меня, не обеспокоен.