ASP.net структура проекта MVC

Я создал следующую структуру проекта для моего нового asp.net проект mvc любой я был после некоторой обратной связи, как другие люди структурируют свои проекты, и если бы я улучшил свой...

вот что у меня пока есть:

+Assets
-+Images 
-+Scripts 
-+Stylesheets 
-+...              'More things like the above here
+Controllers 
-+Support
--+Actions         'Any custom action classes
--+Controllers     'Base controller classes
+Models
-+Domain           'Contains any class that specialise view specific domain logic
--+UrlProcessing   'Encoding/decoding business entities as URL parts 
--+...             'More things like the above here
-+Views            'Contains view models
--+Support
---+Views          'Base classes for any view models
+Support
-+Application      'Global application interface classes (i.e. class that wraps the function of the global asax)
-+Configuration    'Typed config classes
-+Helpers          'Where you put additional html helper classes, etc
-+Services
--+Bootstrap       'Tasks that run on mvc start-up that are specific to the MVC project
--+Inversion       'Specific IoC registration registrations for this project 
--+...             'More things like the above here
+Views
-+Home
-+Shared 
-+...              'More things like the above here

Ура Энтони

10
asp.net asp.net-mvc solution

4 ответов

У меня похожая структура с некоторыми исключениями:

  1. поддержка называется инфраструктурой (пространство имен только для использования сборки пользовательского интерфейса)
  2. IoC находится в другом проекте (Проект Для глобально используемой функциональности инфраструктуры). UI имеет реестр StructureMaps только с именами сборок (IOC инициализируется соглашением). Подход типа украденный из источника CodeCampServer. Logging, разделы конфигурации идут здесь тоже.
  3. Views / [ControllerName] имеет частичную подпапку, которая может быть еще более разделена
    (это включает в себя жонглирование ViewEngine, чтобы он мог найти представления / частичные представления).
  4. Views/[ControllerName] имеет папку LocalResources (с частичной подпапкой)
  5. не добавили вложенную папку под контроллерами (...еще.) Мне нравится держать их чистыми и довольно глупыми.

и еще несколько исключений, связанных с моделью:

  1. вся бизнес-логика живет в сборку домен, домен.Пространство имен модели с некоторой помощью уровня инфраструктуры для технических аспектов.
  2. View models (я называю их ViewData) живет в сборке UI в папке ViewData, структурированной в папках, похожих на представления. Выбранный подход из Kigg (за исключением того, что я структурирую их на представление, как SearchViewData, иногда даже на частичное представление).

все работает достаточно хорошо до сих пор

обратите внимание, что структурирование ViewData (я даже структурирую свой javascript таким же образом, View==JS-файл, который содержит все под объектом с именем [ViewName]) per view может быть неприемлемым для более сложных веб-сайтов.

4

сайт MVC
app -все статические файлы
-- common
----в CSS
------ стили-большинство-страниц-использование.в CSS
---- imgs
------ изображения-большинство-страницы-использование.формат PNG
---- js
------ваш-заказ-Либ.js
--файлы
----release_notes.МД
----Примечания к выпуску.HTML-код
-- страницы!--3--> ---вход
------ сигнин.в CSS
------лого.формат PNG
------ сигнин.js
---- приборная панель
------инструментальная панель.js
--поставщики
----в jQuery
------в jQuery.1.11.1.js
-_ссылки на литературу.js

контроллеры - только тонкие контроллеры, просто код для вызова основных функций библиотеки
Модели -только модели, которые используются для отображения вида
Просмотров -только клиентский код, такой как html, razor, css и т. д.

основная библиотека
В основном весь код...доступ к данным, пользовательские атрибуты, коммунальные услуги и т. д. Разделение основного кода только на библиотеку удобно по многим причинам. Теперь ваша логика не привязана только к веб-сайту. Если мне нужно я могу построить быстрый передний конец в WinForms, чтобы проверить некоторую логику, или я мог бы использовать то же самое функции на уровне доступа к данным для создания интерфейса администратора для базы данных.

Я считаю эту структуру самой простой и гибкой для меня.

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

обновление 8-21-15 В последнее время я работаю над большими проектами и отделяю основную библиотеку от собственного проекта Visual Studio. Это делает его гибким при использовании внешних SVN. Я могу использовать одну и ту же библиотеку в разных проектах и только нужно сделать обновление SVN, чтобы получить изменения. Также вспыхнул сайт MVC в собственном проекте.

5

Я написал пару (небольших) сайтов и просто застрял с той же структурой, что и NerdDinner, и, казалось, работал нормально.

Я думаю, что в небольших проектах это прекрасный подход, пока у вас есть разделение проблем, не размещайте бизнес-логику в репозитории (- ах) и т. д. Соблазн в меньшем проекте-размыть линии, но MVC имеет тенденцию немного наказывать вас, когда вы это делаете. :)

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

1

Я думаю, что это немного усложнено, но если это имеет смысл для вас пойти с ним. Важно сохранять равновесие.

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

1