Должно ли внутреннее приложение C # быть скомпилировано с бизнес-логикой? - PullRequest
2 голосов
/ 02 апреля 2009

[фон]

Итак, у меня есть приложение на C #, которое было написано до того, как я сюда попал. В настоящее время я не в dev org, но я являюсь техническим лидером в моей подгруппе в организации интернет-маркетинга. Я отвечаю за автоматизацию процессов, минимальную поддержку настольных компьютеров и создание пользовательских приложений, которые облегчают нашу жизнь.

[/ фон]

[подробности приложения]

У нас есть приложение, которое создает пользовательский файл базы данных из списка URL-адресов. Он был спроектирован так, чтобы иметь один входной файл и два выходных файла для двух приложений, которые используют файлы подобного типа. Правило разницы между двумя выходными файлами компилируется в код.

[/ app details]

Должно ли внутреннее приложение C # быть скомпилировано с бизнес-логикой, которую нельзя изменить без перестройки?

Ответы [ 6 ]

11 голосов
/ 02 апреля 2009

Внутренние приложения имеют одну цель: поддержать процесс.

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

Как всегда, ответ должен быть "это зависит".

2 голосов
/ 02 апреля 2009
  • Сколько времени нужно, чтобы изменить бизнес-логику и затем перекомпилировать?
  • Сколько времени займет изменение бизнес-логики без перекомпиляции в новой версии?
  • Сколько времени потребуется, чтобы перекодировать его?
  • Как это повлияет на обслуживание с точки зрения дополнительных часов, проведенных в будущем?
  • Кто-нибудь из людей, которым необходимо приложение, не может изменить бизнес-логику, потому что она в форме кода?

Ответ на эти 5 вопросов даст ответ.

2 голосов
/ 02 апреля 2009

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

1 голос
/ 02 апреля 2009

Если логику не нужно менять, тогда да, вероятно, ее следует скомпилировать вместе с кодом.

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

0 голосов
/ 26 января 2010

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

Прежде всего никогда вставлять бизнес-правила в код, не документируя их каким-либо образом. В коде много переменных, и только некоторые из них можно безопасно изменить, сохраняя при этом правильное поведение. Обычно я ставлю константу в начале урока, чтобы определить, какое поведение можно изменить, т. Е.

// Prefer this
const int AllowDownloadAttempts = 2;
if (AttemptDownload() > AllowDownloadAttempts) RegisterAndAllowDownload();

// Over this
if (AttemptDownload() > 2) RegisterAndAllowDownload();

Основное правило, которому я следую, - это что-либо кроме [-1, 0, 1], которое должно быть задокументировано.

Если это не критично и вряд ли будет часто меняться, я бы поместил его в файл конфигурации приложений (например, App.config) и получил доступ к нему через строго типизированный класс конфигурации, чтобы вы могли отслеживать его использование, чтобы знать, когда его безопасно удалить или изменить.

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

0 голосов
/ 02 апреля 2009

Конечно, если вы знаете, что утилита будет использоваться только в вашей организации, и для одной цели нет ничего плохого в том, чтобы смешивать ваши бизнес-правила с логикой. Чрезмерное проектирование (в этом случае повторное использование кода, когда он никогда не будет использоваться повторно) не будет эффективным использованием ресурсов.

...