Избавление от твердых кодированных значений при контакте со справочными таблицами и связанной бизнес-логикой
Если Вы работаете с.Net 3.5, можно хотеть изучить библиотека насмешки Moq - это использует деревья выражений и лямбды для удаления неинтуитивной идиомы рекордного ответа большинства других библиотек насмешки.
Выезд этот быстрый запуск для наблюдения, сколько еще интуитивный тестовые сценарии становятся вот простой пример:
// ShouldExpectMethodCallWithVariable
int value = 5;
var mock = new Mock();
mock.Expect(x => x.Duplicate(value)).Returns(() => value * 2);
Assert.AreEqual(value * 2, mock.Object.Duplicate(value));
8 ответов
По моему опыту, это тот случай, когда вы на самом деле должны жестко запрограммировать , предпочтительно используя Enum, целые значения которого соответствуют идентификаторам ваших таблиц поиска. Я не вижу ничего плохого в том, чтобы сказать, что «1» всегда «Доступен» и так далее.
Большинство систем, которые я видел, жестко кодируют значения таблицы поиска и живут с этим. Это потому, что на практике кодовые таблицы редко меняются так сильно, как вы думаете. И если они когда-либо изменятся, вам, как правило, необходимо перекомпилировать любые программы, которые в любом случае полагаются на этот DDL.
Тем не менее, если вы хотите сделать код поддерживаемым (похвальная цель), лучшим подходом будет экстернализация значения в файл свойств. Затем вы можете отредактировать этот файл позже, не перекодируя все приложение.
Ограничивающим фактором здесь является то, что ваше приложение зависит для своего внутреннего состояния от значения, которое вы получаете из таблицы поиска, так что это подразумевает определенную сумму сцепления.
Для запросов, в которых приложение не полагается на этот код (например, если в вашей кодовой таблице хранится список двухбуквенных кодов состояний для использования в раскрывающемся списке адресов), вы можете лениво загружать коды в объект и обращаться к ним только при необходимости. Но это не сработает для того, что вы делаете.
Когда в коде определены таблицы поиска и перечисления, у вас всегда есть проблема с их синхронизацией. Здесь мало что можно сделать. Оба эффективно живут в двух разных мирах и обычно не знают друг друга.
Вы можете отказаться от использования таблиц поиска и позволить только вашей бизнес-логике оперировать этими значениями. В этом случае вы упускаете возможность полагаться на ссылочную целостность для обеспечения целостности данных.
Другой вариант - построить приложение таким образом, чтобы эти значения никогда не понадобились в вашем коде. Это означает перемещение части вашей бизнес-логики на уровень базы данных, то есть размещение их в хранимых процедурах и триггерах. Это также будет способствовать тому, что клиент будет агностиком.
Вам понадобится какое-то предопределенное значение, которое никогда не изменится, будь то целое число, строка или что-то еще.
В вашем случае числовое значение состояния - это состояние состояния суррогатный ПЕРВИЧНЫЙ КЛЮЧ , который никогда не должен изменяться в хорошо спроектированной базе данных.
Если вас беспокоит согласованность, используйте код CHAR : A , R или B .
Однако вы должны придерживаться его, а также цифрового кода, чтобы A всегда означало Доступно и т. Д.
Структура вашей базы данных должна быть документирована так же, как и код.
Ответ полностью зависит от языка, который вы используете: решения для этого не совпадают в Java, PHP, Smalltalk или даже Assembler ...
Но позвольте мне сказать вам кое-что : хотя это правда, что жестко запрограммированные значения - не самое лучшее, бывают случаи, когда они вам действительно нужны. И этот в значительной степени один из них: вам необходимо указать в своем коде ваше текущее знание бизнес-логики, которая включает эти жестко закодированные состояния .
Итак, в этом конкретном случае я бы жестко закодируйте эти значения.
Не переоценивайте его. Прежде чем пытаться найти решение этой проблемы, нужно разобраться, проблема ли это вообще. Можете ли вы придумать какой-либо допустимый гипотетический сценарий, в котором вы бы изменили значения в таблице itemState? Не просто «Что, если кто-то изменит эту таблицу?» но «Кто-то хочет изменить эту таблицу X способом по Y причине, какой эффект это будет иметь?». Вы должны оставаться реалистами.
Новое состояние? вы добавляете строку, но это не влияет на существующие. Удаление состояния? Вы все равно должны удалить ссылки на него в коде. Изменить идентификатор состояния? Для этого нет никаких законных оснований. Меняете название штата? Для этого нет законной причины.
Так что действительно не должно быть причин для беспокойства по этому поводу. Но если вам нужно, чтобы это было легко обслуживаемым в случае иррациональных людей, которые случайным образом решают изменить Доступно на 2, потому что это лучше соответствует их фэн-шуй, убедитесь, что все таблицы созданы с помощью сценария, который считывает эти значения из файла конфигурации, затем убедитесь, что весь код считывает константы из того же файла конфигурации. Тогда у вас есть одно место определения, и каждый раз, когда вы хотите изменить значение, вы изменяете этот файл конфигурации вместо DB / кода.
Я использовал метод, аналогичный тому, что вы описываете, - таблицу в базе данных со значениями и описаниями (полезно для отчетов и т. Д.) И перечисление в коде. Я обработал синхронизацию с помощью комментария в коде, в котором говорится что-то вроде «эти значения взяты из таблицы X в базе данных ABC», чтобы программист знал, что базу данных необходимо обновить. Чтобы предотвратить изменения со стороны базы данных без соответствующих изменений в коде, я установил разрешения для таблицы так, чтобы только определенные люди (которые, надеюсь, помнят, что им тоже нужно изменить код) имели доступ.
Я думаю, что это обычная проблема и серьезное беспокойство, поэтому я сначала погуглил и нашел эту статью.
Как насчет создания общедоступного статического класса для хранения всех значений поиска, но вместо жесткого кодирования мы инициализируем эти значения при загрузке приложения и используем имена для ссылки на них?
В моем приложении мы попробовали это, и это сработало. Также вы можете выполнить некоторую проверку, например. количество различных возможных значений поиска в коде должно быть таким же, как и в db, если это не так, log / email / и т. д. Но я не хочу вручную кодировать это для статуса более 40 бизнес-сущностей.
Более того, это может быть частью более серьезной проблемы отображения OR. Мы выставляем слишком много деталей на уровне персистентности, и поэтому мы должны позаботиться об этом. С такими технологиями, как Entity Framework, нам не нужно беспокоиться о части «синхронизации», потому что она автоматизирована, я прав?
Спасибо!