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

Ура Энтони


asp.net asp.net-mvc solution
person vdh_ant    schedule 07.07.2009    source источник
comment
Чувак.. попробуй скрин в следующий раз :(   -  person Pure.Krome    schedule 07.07.2009
comment
Я должен был сделать, чтобы размещение изображения было проблемой, хотя ...   -  person vdh_ant    schedule 08.07.2009
comment
не беспокойтесь о хостинге. Stackoverflow использует для этого бесплатный сервис.   -  person Gabriele Petrioli    schedule 20.02.2011
comment
Однако вы не можете скопировать вставку со скриншота.   -  person Dennis Smit    schedule 12.02.2012

Ответы (4)


arrow_upward
4
arrow_downward

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

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

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

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

Пока работает достаточно хорошо

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

О... и => папка == пространство имен для меня. Думаю, это хорошая практика.

person Arnis Lapsa    schedule 07.07.2009

arrow_upward
5
arrow_downward

Приложение Сайт MVC
 — все статические файлы
--common
----css
----- -styles-most-pages-use.css
----imgs
------images-most-pages-use.png
----js
------your-custom-lib.js
--files
----release_notes.md
----release_notes.html
--pages
----signin
------signin.css
------logo.png
------signin.js
----dashboard
------dashboard.js
--vendors
----jquery
------jquery.1.11. 1.js
-_references.js

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

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

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

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

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

person Donny V.    schedule 04.03.2011
comment
Я знаю, что ты ответил на этот вопрос несколько месяцев назад. У меня есть сомнения. Если модели используются только для отображения представления, где мы помещаем сервисные функции. Вот где я застрял. Скажем, у меня есть memberModel (которая содержит свойства для отображения представлений членов), тогда где я помещаю «DreateMember ()', 'DeleteMember()', которые имеют доступ к базе данных mysql. Я поместил это в класс с именем Memberservices и поместил в файл memberModel. Правильно ли это? - person Null Pointer; 07.10.2011
comment
CreateMemember() и подобные им функции должны существовать в основной библиотеке, поскольку она имеет бизнес-логику и взаимодействует с вашей базой данных. В вашей модели может быть код, который вызывает эти функции. - person Donny V.; 11.10.2011

arrow_upward
1
arrow_downward

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

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

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

person griegs    schedule 07.07.2009

arrow_upward
1
arrow_downward

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

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

person jgarcia    schedule 07.07.2009