10

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

干杯安东尼

4

4 回答 4

5

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 后，相同的结构运行得非常好。

2015 年 8 月 21 日更新 我最近一直在从事更大的项目，并将核心库分离到它自己的 Visual Studio 项目中。这使得在使用 SVN Externals 时变得灵活。我可以在不同的项目中使用相同的库，并且只需要进行 SVN 更新即可获得更改。也在自己的项目中爆发了 MVC 站点。

于 2011-03-04T16:14:10.193 回答
4

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

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

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

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

到目前为止它工作得很好

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

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

于 2009-07-07T00:42:13.823 回答
1

我写了几个（小）网站，只是坚持使用与 NerdDinner 相同的结构，它似乎工作正常。

我认为在较小的项目上这是一个很好的方法，只要你有你的关注点，不要将业务逻辑放在存储库等中。较小项目的诱惑是模糊界限，但 MVC 往往会惩罚你当你这样做的时候一点点。:)

较大的项目可能会看到您实施一个单独的业务类项目，甚至可能是数据翻译项目等。

于 2009-07-07T00:30:23.153 回答
1

我认为这有点过于复杂，但如果它对你有意义，那就去吧。重要的是保持平衡。

我喜欢在解决方案中使用单独的项目的一件事，因为它允许重用数据访问和业务逻辑，以供其他客户端应用程序类型（如 WPF 或 WinForms 客户端）重用。

于 2009-07-07T03:58:14.120 回答