Нужно ли использовать несколько сборок для изолированного веб-приложения ASP.NET?

Question

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

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

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

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

Я хотел знать, что думают об этом сообществе.

---

Позвольте мне добавить больше информации ...

Я пишу это приложение, используя предварительный просмотр MVC 5, поэтому часть модульного тестирования будет поддерживаться разделением проблем, унаследованных в рамках. Мне нравится делать тесты для всего!

Answer 1

Начните с самой простой вещи и добавьте сложности, если и когда потребуется. Звучит так, как будто одна сборка подойдет для вашего случая. Однако старайтесь не нарушать слои, поскольку слой A имеет доступ к внутреннему элементу слоя B. В дальнейшем это затруднит перенос слоев в отдельные сборки.

Answer 2

Вы все равно должны логически разделять слои на соответствующие проекты.

Это хорошая инженерная практика, будь вы всего лишь 1 разработчиком или 100. Недостатком кода в одном месте является то, что он заставит вас сделать рефакторинг или дублировать код для расширения.

Answer 3

Я бы сказал, это зависит от того, насколько серьезно вы относитесь к тестированию и юнит-тестированию.

Если вы планируете проводить только пользовательские / ручные тесты или использовать в основном только тестирование из пользовательского интерфейса, то это на самом деле не имеет значения.

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

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