Как программировать три выпуска Свет, Pro, Окончательный в одном решении
Я хотел бы знать, как лучше всего программировать три различных выпуска моего ASP.NET C# 3,5 приложения в Профессионале VS2008 (который включает веб-проект развертывания). У меня есть Свет, Pro и Окончательный выпуск (или версия) моего приложения. В данный момент я поместил все в одно решение с тремя версиями сборки в менеджере конфигурации, и я использую директивы препроцессору на всем протяжении кода (приблизительно в десяти тысячах строк кода существует приблизительно 20 таких конструкций, таким образом, это сверхвидимо):
#if light
//light code
#endif
#if pro
//pro code
#endif //etc...
Я читал в stackoverflow в течение многих часов и думал, чтобы встретиться, как, например, Microsoft делает это с ее различными выпусками Windows, но не нашел то, что я ожидал. Где-нибудь существует тяжелая дискуссия о том, если директивы препроцессору являются злыми.
То, что я люблю с теми #if-directives:
- бок о бок код различий, таким образом, я пойму код для различных выпусков после шести месяцев
- и специальное преимущество для НЕ выделения скомпилированного кода других версий клиенту.
Хорошо, долгое объяснение, повторный вопрос: что состоит в том, чтобы пойти лучший способ?
3 ответа
я был бы склонен управлять различиями во время выполнения с помощью разных лицензий, и включать/выключать функции, используя эту конфигурацию. Зачем?
- Вам нужно создать только один развертываемый модуль.
- вы можете гораздо легче протестировать его, вместо того, чтобы создавать 3 версии и тестировать их.
- пользователи могут обновиться и просто получить новую лицензию. Им не придется обновлять/переустанавливать.
Вы должны сопоставить это с вашими опасениями по поводу распространения решения, за которое ваши клиенты фактически не заплатили (и могут просто включить его с помощью соответствующего безопасного лицензионного ключа).
Моя первая мысль - разделить ваше программное обеспечение на различные модули (проекты / сборки), а затем создать в вашем решении три разных проекта установки, по одному для каждой версии. В настройку вы включаете только нужные вам модули.
Вы потеряете "параллельный" код, но ИМХО, это просто создает сложные методы вместо поддерживаемого кода. Используйте методы расширения, если вы хотите предоставить больше функциональных возможностей для типа, или наследовать классы.
Я бы предложил создать основные классы и функции как обычно, но разрешить переопределение для тех методов, которые будут специфичны для конкретного издания.
затем вы создаете сборку light/pro/ultimate edition, которая переопределяет эти методы.
затем вам нужна фабрика, которая создает правильные типы переопределения в зависимости от редакции.
здесь вы могли бы работать с internal-accessor и сделать внутренний код сборки видимым для edition-сборок