Какой должна быть структура MVC проекта? - CodeHelper

Какой должна быть структура MVC проекта?

2

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

  1. Каждую подсистему реализовывать в отдельной сборке со своими пространствами имен: Models, Views, Controllers?
  2. Создать три общие сборки: Models, Views, Controllers?

Наверняка этот вопрос можно рассматривать с разных аспектов. Вот хотелось бы рассмотреть этот вопрос с разных позиций. Быть может, есть какие-то рекомендации, best practice, так сказать?

Alexander

Вероятно, тут все зависит от размера приложения, от количества связей между подсистемами. Первый вариант, при условии выноса общих частей в отдельные сборки ядра, представляется мне более правильным. Скажем так:

  • Application.Core.Models
  • Application.Core.Controllers
  • Application.Core.Views
  • Application.Subsystem1
  • ...
  • Application.SubsystemN

Новые ответы


1

Есть родственные вопросы насчет пакетирования и организации структуры проекта.

Один из принципов пакетирования гласит, что «должна быть толко одна причина для изменения пакета». То есть любое изменение должно быть локализовано и должно затрагивать только определенные сборки. Вариант, при котором есть три проекта Models, Views, Controllers не отвечает этому принципу, потому что любое изменение будет сквозным — оно затронет и модель и виды и контроллеры. Если же разбивать на проекты по логическим частям, то для каждой такой части можно проводить локальные изменения не затрагивая другие.

Вообще задача пакетирования достаточно запутанная, и, покрайней мере в .NET, каждый организует структуру проекта исходя из личных предпочтений, а не best practices.


v1.7.123.556
© 2009—2010 CodeHelper FAQ | О сайте | Обратная связь | История изменений | Статьи
Creative Commons LicenseМатериалы сайта распространяются под лицензией Creative Commons Attribution-Share Alike 3.0 Unported.