Наилучшая практика для структурирования нового большого решения ASP.NET MVC2 plus EF4 VS2010?

Question

мы создаем новое веб-приложение, используя Microsoft ASP.NET MVC2 и Entity Framework 4. Хотя я уверен, что нет правильного ответа на мой вопрос, мы изо всех сил пытаемся согласовать структуру решения VS2010.

Приложение будет использовать SQL Server 2008 с возможной будущей облачной версией Azure. Мы используем EF4 с T4 POCO (сначала модель) и получаем доступ к ряду сторонних веб-сервисов. Мы также будем подключаться к ряду внешних систем обмена сообщениями. Пользовательский интерфейс основан на стандартном ASP.NET (MVC) с jQuery. В будущем мы можем предоставить версию Silverlight / WPF, а также мобильную версию.

Проще говоря, мы начинаем с пустого решения VS2010 - тогда что? Я предложил 4 папки Data (файл EF edmx и т. Д.), Домен (сущности, репозитории), Службы (доступ к веб-службам), Презентация (веб-интерфейс и т. Д.). Однако в Presentation создание проекта ASP.NET MVC2, очевидно, создает свою собственную папку Models и т. Д., И, похоже, она не слишком хорошо вписывается в эту предложенную структуру. Мне также не хватает бизнес-уровня (или он находится в домене?).

Опять же, я уверен, что нет единственно правильного способа сделать это, но я очень ценю ваши взгляды на это.

Спасибо

Answer 1

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

Что касается структурирования и MVC-проекта, единственная действительно важная папка - это Views. Я начал отрываться от структуры папок / Controllers и / ViewModels и группировать вещи по концепции домена. Если ученик является одной из концепций вашего домена, у меня будет папка «Студенты» в проекте домена, в папке «MVC Views», в проекте служб и т. Д. Все классы домена, модели представлений, контроллеры и т. Д. Будут проходить под одной и той же имя папки (в разных проектах). Таким образом, вы всегда будете точно знать, куда идти, если хотите изменить код, связанный с Student.

Кроме того, у нас есть веб-проект, в котором размещены представления, и отдельный проект библиотеки классов, содержащий контроллеры. У большинства моих решений 12-30 проектов.

Answer 2

Хотели добавить - не так важно, как Вы организуете свои папки / решения, важно, как Вы организуете свой код .

Итак - если ваше приложение не будет должным образом наслоено с использованием таких причудливых методов, как инверсия зависимостей, не будет аккуратным и тестируемым - не будет иметь значения, если вы поместите вонючий код в одну или сто папок. Вы не сможете перейти с sql на Azure, с mvc на silverlight.

Answer 3

Полагаю, вы правы, рассматривая структуру проекта (и пространства имен) на этом раннем этапе. Хотя точка зрения jfar хорошо сформулирована, как часто вам предоставляется роскошь реструктурировать свои проекты и пространства имен до первого выпуска? Даже то, что вы предлагаете, лучше, чем бросать все в один и тот же проект - конечно?

Answer 4

Вы можете посмотреть это видео от Роба Конери, чтобы узнать, как структурировать ваш проект MVC: http://blog.wekeroad.com/2010/04/19/tekpub-starter

http://tekpub.com/production/starter

НТН

Answer 5

Что имеет смысл для вас и вашей команды?

В какой папке находится код, ничего не значит (кроме незначительной генерации пространства имен) и может быть легко изменен перетаскиванием.

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

С моими личными проектами я сваливаю все в один проект, на работе у меня есть 17 проектных решений и 50 папок. Код есть код.