【问题标题】:ASP.net MVC project structureASP.net MVC 项目结构
【发布时间】:2009-07-07 00:16:12
【问题描述】:

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


【解决方案1】:

MVC 网站
应用程序 - 所有静态文件
--常见
----css
------styles-most-pages-use.css
----图片
------图片最多页面使用.png
----js
------你的自定义lib.js
--文件
----release_notes.md
----release_notes.html
--pages
----登录
------signin.css
------logo.png
------signin.js
----仪表板
------dashboard.js
--供应商
----jquery
------jquery.1.11.1.js
-_references.js

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

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

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

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

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

【讨论】:

  • 我知道你几个月前就回答了。我有一个疑问。如果模型只用于显示视图,我们将服务功能放在哪里。这就是我坚持的地方。说,我有一个 memberModel(其中包含显示成员视图的属性)然后我把'DreateMember ()', 'DeleteMember()' 具有 mysql 数据库访问权限的函数。我把它放在一个名为 Memberservices 的类中,然后把它放在 memberModel 文件中。这样对吗?
  • CreateMemember() 和类似的函数应该存在于核心库中,因为它具有业务逻辑并与您的数据库对话。您可以在模型中包含调用这些函数的代码。
【解决方案2】:

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

  1. 支持被命名为 Infrastructure(命名空间仅用于 UI 程序集)
  2. IoC 在不同的项目中(全球使用的基础设施功能项目)。 UI 的 StructureMaps Registry 仅具有程序集名称(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] 的对象下的所有内容) 对于更复杂的网络,可能无法接受每个视图网站。

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

【讨论】:

    【解决方案3】:

    我已经编写了几个(小型)网站,只是坚持使用与 NerdDinner 相同的结构,而且它似乎运行良好。

    我认为对于较小的项目,这是一种很好的方法,只要您将关注点分开,不要将业务逻辑放在存储库等中。较小项目的诱惑是模糊界限,但 MVC 倾向于在你这样做的时候惩罚你一点。 :)

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

    【讨论】:

      【解决方案4】:

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

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

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2010-10-01
        • 2010-11-24
        • 2015-06-04
        • 2021-02-19
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多