Типичное практическое правило для разделения частей кода на отдельные проекты

Question

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

I 'Я просто пытаюсь работать над организацией проектов и кода внутри.

Когда вы должны начать делить свой код на отдельные проекты?Не могли бы вы также привести пример?

Спасибо

Answer 1

Я часто вижу изменения в чем-то вроде:

• Веб-приложение
• Сервисный уровень
• Бизнес-уровень
• Уровень данных
• Модульные тесты
• Интеграционные тесты

Один из способов получить идею - найти проекты с открытым исходным кодом asp.net MVC и посмотреть, как они это делают.

Для альтернативного способа выше вы можете проверить CodeCampServer .Они использовали Onion Architecture для макета своих проектов.

Луковая архитектура отличается от той, что была изложена выше, и у них есть отличное объяснение, почему (веб-трансляция).

Снимки, сделанные с указанной выше веб-страницы.

Ключевые принципы Onion Architecture:

• Приложение построено вокруг независимой объектной модели • Внутренняяслои определяют интерфейсы.Внешние уровни реализуют интерфейсы • Направление связывания направлено к центру • Весь код ядра приложения может быть скомпилирован и запущен отдельно от инфраструктуры

Ссылка на Onion Architecture с примером с открытым исходным кодом дает обоснование того, когда и почемуи конкретный пример, чтобы поиграть, если вам это нравится.

Answer 2

Чаще всего в моих приложениях целью разделения кода на разные проекты является повторное использование кода.На самом деле нет никаких жестких правил, но вот несколько принципов, которым я стараюсь следовать.

Для повторного использования кода я рассматриваю, пригоден ли класс, который я пишу, в другом контексте.Например, если у меня есть веб-сайт ASP.NET, который общается с базой данных, код доступа к данным может быть повторно использован в приложении на базе Windows, поэтому он является хорошим кандидатом для включения в свою собственную библиотеку.

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

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