Структура проекта 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

Приветствия Энтони

ОТВЕТЫ

Ответ 1

У меня есть аналогичная структура с некоторыми исключениями:

  • Поддержка называется Infrastructure (пространство имен для использования только для пользовательского интерфейса)
  • IoC находится в другом проекте (проект для глобальной функциональности инфраструктуры). UI имеет реестр StructureMaps только с именами сборок (IoC инициализируется по соглашению). Тип подхода, украденный из источника CodeCampServer. Здесь также находятся разделы журнала, конфигурации.
  • Views/[Имя_контроллера] имеет частичную подпапку, которая может быть еще более разделена
    (это связано с манипуляцией с ViewEngine, чтобы он мог найти представления/частичные представления).
  • Views/[Имя_контроллера] имеет папку LocalResources (с частичной подпапкой)
  • Не добавляйте подпапку под контроллерами (... еще). Мне нравится держать их в чистоте и совершенно глупо.

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

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

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

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

Oh... and = > folder == namespace для меня. Я думаю, что хорошая практика.

Ответ 2

Сайт MVC
app - все статические файлы
--common
---- CSS
------ стили-самая-страница-use.css
---- ГИМ
------ образами-самая-страница-use.png
---- JS
------ ваш обычай-lib.js
--files
----release_notes.md
---- release_notes.html
--pages
---- зарегистрировались
------ signin.css
------ logo.png
------ signin.js
---- приборная панель
------ dashboard.js
--vendors
---- JQuery
------ jquery.1.11.1.js
-_references.js

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Одна вещь, которая мне нравится делать с отдельными проектами в рамках решения, поскольку это позволяет повторно использовать Data Access и Business Logic для повторного использования другими типами клиентских приложений, такими как WPF или WinForms Clients.

Ответ 5

У меня глупый вопрос относительно структуры проекта. Имеет ли значение, куда я помещаю папку с моими шрифтами, или это зависит только от меня? Я новичок в ASP.net, и во всех старых уроках папка шрифтов автоматически добавлялась при создании проекта.

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