У меня есть настольное приложение WPF prism с несколькими модулями. В прошлом я помещал все свои локализованные ресурсы в общие файлы ресурсов в сборке инфраструктуры и ссылался на них во всех модулях.
Но в последнее время мне стало интересно, действительно ли это правильный подход с точки зрения обслуживания. По сути, это также нарушает модульность. Будет ли в долгосрочной перспективе лучшим подходом наличие файлов ресурсов, специфичных для модулей, в самих модулях?
Все мысли оценены.
Поскольку одной из основных целей Prism является модульность, кажется очевидным вкладывать свои ресурсы только в соответствующую сборку. Совместное использование ресурсов через одну централизованную сборку является противоположностью модульности. Делая это централизованно, вы получите еще один тип ада DLL в то время, когда вы захотите добавить больше (необязательных) модулей. Придется обновлять общую сборку без знания модулей, использующих сборку. И определение того, какой модуль присутствует, просто снова нарушает саму модульность. Другой способ — всегда обновлять общую сборку до последней версии. Что бы вы ни делали, следование централизованному подходу заставляет вас создавать обратно совместимые все ваши модули.
Это моя точка зрения на данный момент. Но поскольку я работаю с Prism всего несколько недель, я не совсем уверен, правильно ли мое утверждение, как это должно быть сделано.
У меня никогда не было ссылок между отдельными модулями при использовании Prism (если только один модуль не является расширением другого). Я стараюсь помещать общие ресурсы, интерфейсы и т. д. в «общую» сборку, на которую ссылаются все модули и сборка, содержащая оболочку. Вещи, которые реализуют интерфейс, затем извлекаются через IoC-контейнер, и реализация помещается в модуль, которому она «принадлежит».
Как вы пишете - наличие их в модуле инфраструктуры ломает одну из идей Prism.
