Где разместить уникальные настройки при использовании абстрактного базового класса

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

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

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

Идея состоит в том, чтобы иметь один базовый проект (dll), один проект системного приложения для каждой системы (dll), а затем помещать индивидуальные настройки клиента в один уникальный проект клиента (dll).
Rob.Core.dll
Rob.Application.BigSystem.dll
Rob.Application.BigSystem.Customer.BigCompany .dll

Rob.Core.dll — это базовый абстрактный проект.
Rob.Application.BigSystem.dll — это системный проект (BigSystem), производный от Rob.Core.dll.
Rob.Application.BigSystem.dll должен проверить, есть ли у текущего клиента, BigCompany, какие-либо уникальные настройки, и, если да, загрузить файл Rob.Application. Сборка BigSystem.Customer.BigCompany.dll, которая может содержать переопределения методов или расширений объектов, дополнительные поля и т. д.

Что ж, время подвести итоги...
Я не уверен, куда идти, я мог бы создать один базовый проект (абстрактный) и из каждой системы вывести конкретный проект, похоже, это способ начать.
Затем создайте новый проект для каждого клиента с набором уникальных настроек и просто переопределите все методы в конкретном системном проекте.
Тогда проблема в том, какой проект выполняется во время выполнения? Системный проект или уникальный проект заказчика?
Если выполняется системный проект, как он должен загрузить все настройки клиента (если они есть, не каждый клиент получил уникальные настройки)?

Это довольно большой вопрос, но я надеюсь на некоторые советы, которые помогут мне написать архитектуру.

С уважением
Роберт


.net architecture abstract-class external assemblies
person Robert    schedule 08.06.2009    source источник
comment
Проекты не являются производными от других проектов. Типы происходят от других типов.   -  person Jon Skeet    schedule 08.06.2009
comment
Небольшая ошибка с моей стороны...   -  person Robert    schedule 08.06.2009

Ответы (1)


arrow_upward
1
arrow_downward

Мои два предложения, из того, что вы сказали:

Я бы сосредоточился на типах, а не на проектах. «Проекты» - это просто способ создать сборку, полную пригодных для использования типов - они сами по себе ничего не наследуют, не допускают создания подклассов и т. д. Вопросы, которые я бы задал: какие типы должны быть быть настроены для клиента? Как будет происходить эта настройка?

Как только вы это выясните, я бы предложил изучить внедрение зависимостей или структуры расширяемости. Хорошим фреймворком для внедрения зависимостей будет Ninject. Хорошей инфраструктурой расширения является MEF.

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

person Reed Copsey    schedule 08.06.2009
comment
Ммм, тут неправильная терминология... Хорошо, допустим, что моя базовая сборка содержит класс (тип), содержащий абстрактные методы для входа и выхода. Системная сборка наследует этот класс (тип) и реализует Login и Logout, эти методы закодированы для указанной системы. Затем приходит клиент №1 и хочет получить дополнительную функциональность, когда вызывается вход в систему, а выход остается нетронутым. Одним из решений является загрузка уникальной сборки клиента с помощью параметра (app.config или аналогичного) из сборки приложения. Но это должен быть какой-то лучший способ сделать это... - person Robert; 08.06.2009
comment
@Robert: Взгляните на MEF - это хороший кандидат на расширяемость. С MEF у вас может быть это так, что вы помещаете DLL в подпапку, и если она реализует определенный тип, система просто находит ее и внедряет дополнительные функции в приложение. Это всего лишь вопрос определения того, где и как типы могут быть расширены... - person Reed Copsey; 09.06.2009
comment
@Reed: Я сделаю это и опубликую свои результаты! - person Robert; 09.06.2009
comment
@Reed: Я провел некоторое тестирование и должен сказать, что это компетентная библиотека, и кажется, что это решит мои проблемы. Большое спасибо! - person Robert; 09.06.2009