ASP.net MVC项目结构

Question

我已经为我的新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

干杯安东尼

Answer 1

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

控制器 - 只有瘦控制器,只是调用核心库函数的代码
模型 - 只用于显示视图的模型
视图 - 只有客户端代码,如html,razor,css等

核心库
基本上所有代码......数据访问,自定义属性,实用程序等.由于许多原因,将核心代码分离到库只是很方便.您的逻辑现在并不仅限于网站.如果我需要,我可以在WinForms中构建快速前端来测试某些逻辑,或者我可以在数据访问层中使用相同的函数来为数据库构建管理前端.

我发现这个结构对我来说是最简单和最灵活的.

更新
我更新了静态内容文件结构,使其更加灵活和现代化.在使用AngularJS时,我想出了这个结构.我最终转向RactiveJS.转移到RactiveJS后,相同的结构非常有效.

更新8-21-15 我最近一直致力于大型项目,并将Core库分离到自己的Visual Studio项目.这使得在使用SVN外部时更加灵活.我可以在不同的项目中使用相同的库,只需要进行SVN更新即可获得更改.同样在自己的项目中爆发了MVC网站.

Answer 2

我得到了与你类似的结构，但有一些例外：

1. 支持被命名为基础设施（仅用于 UI 程序集使用的命名空间）
2. IoC 位于不同的项目中（全球使用的基础设施功能项目）。UI 具有仅包含程序集名称的 StructureMaps 注册表（IoC 按惯例初始化）。方法是从 CodeCampServer 源代码中窃取的。日志记录、配置部分也放在这里。
3. Views/[ControllerName] 有 Partial 子文件夹，该子文件夹可能会更加分散
   （这涉及与 ViewEngine 的配合，以便它可以找到视图/部分视图）。
4. Views/[ControllerName] 有 LocalResources 文件夹（带有 Partial 子文件夹）
5. 尚未在 Controllers 下添加任何子文件夹（...）。我喜欢保持它们干净而且很愚蠢。

还有一些与模型相关的例外情况：

1. 所有业务逻辑都位于域程序集、Domain.Model 命名空间中，并在技术方面有基础设施层的帮助。
2. 视图模型（我称之为 ViewData）位于 ViewData 文件夹下的 UI 程序集中，其结构与视图类似。从 Kigg 中选择了方法（除了我像 SearchViewData 一样按视图构建它们，有时甚至按部分视图构建它们）。

到目前为止效果还不错

请注意，对于更复杂的网站，每个视图构建 ViewData （我什至以相同的方式构建我的 javascript，View==JS 文件，其中包含名为 [ViewName] 的对象下的所有内容）可能不可接受。

哦...对我来说=>文件夹==命名空间。我想这是一个很好的做法。