В настоящее время я работаю над несколькими веб-приложениями .NET (MVC), которые являются функционально независимыми. Мы сохранили наши проекты для каждого инкапсулированного после разделения проблем. Итак, мы закончили с проектами, как:Принципы проектирования, такие как SoC в контексте общей библиотеки
App.DataAccess
App.Services
App.WebApi
App.Domain и т.д.
Существует кусок кода которые эффективно разделяются между двумя компонентами, и они были разделены на собственные проекты.
Общие/Core.DataAccess
Общие/Core.Services
Общие/Core.Domain
Общие/Core.WebApi и т.д.
Положение мы работаем над исправлением в настоящее время заключается в том, что этот «общий код» в основном дублируется для обоих приложений, и мы используем процесс в качестве полосовой поддержки, чтобы синхронизировать их между двумя приложениями.
После некоторых исследований, мое предложение до сих пор было:
1) Создать частный канал NuGet (размещенного на нашем собственном сервере)
2) Дайте общий код свое собственное решение и вытолкнуть к этому фиду.
3) Оба приложения теперь устанавливают этот общий код как пакет nuget.
В целом, все довольны этим подходом. Разногласия возникают из-за структурирования этого нового решения.
В настоящее время общий объем состоит из 9 проектов, при этом некоторые проекты имеют размер как один класс. Крупнейший проект - < 25 файлов. Я чувствую, что мы должны объединить все в один проект и использовать папки и пространства имен для инкапсуляции.
Озабоченность группы состоит в том, что разделение проблем будет нарушено, поскольку наш веб-проект будет ссылаться на этот пакет nuget и иметь доступ к некоторым компонентам доступа к данным.
Есть ли общепринятый шаблон, который следует соблюдать здесь или является лучшим решением для сохранения 9 проектов и 9 пакетов nuget для поддержания SoC?
Цените любое руководство здесь!
~ Saagar