Архитектура: использование разных классов при разработке / производстве - PullRequest
1 голос
/ 16 ноября 2009

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

Пример: класс SQL-запроса, который не проверяет тип / существование полей. Другой пример: класс обработки ошибок, который регистрирует и не отображает сообщения.

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

Ответы [ 4 ]

4 голосов
/ 16 ноября 2009

Это может быть только я ... но это действительно плохая идея.

У вас не должно быть кода, работающего вживую, который вы не запускаете в разработке / тестировании. В противном случае нет способа проверить, работает ли код должным образом (кроме, конечно, его запуска в производство и скрещивания пальцев).

По этой причине я не думаю, что вы найдете хороший пример того, что вы ищете.

Обновление

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

0 голосов
/ 16 ноября 2009

В моем случае у меня есть платежный шлюз с песочницей и живым окружением. я использовал фабричный шаблон + интерфейсы (чтобы все шлюзы имели одинаковую сигнатуру) + конфигурация (когда система знает, какой класс нужно создать)

0 голосов
/ 16 ноября 2009

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

Тем не менее, вы, вероятно, ищете шаблон Factory или Factory Method .

0 голосов
/ 16 ноября 2009

Не очень хорошая идея иметь другой код в разных средах.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...