.net 终极 Visual Studio 解决方案结构

The Ultimate Visual Studio Solution Structure

提问by Chase Florell

Realizing that this could be subjective based on the project at hand, I'm looking for the "best practice" method of structuring a VS (Visual Studio) Solution.

意识到这可能是基于手头项目的主观性，我正在寻找构建 VS（Visual Studio）解决方案的“最佳实践”方法。

Please feel free to edit this, comment on what you think might be incorrect, suggest alternatives, etc. I'd love to see this Community Wiki grow into a great resource for people just starting with VS Solutions.

请随意编辑它，评论您认为可能不正确的内容，建议替代方案等。我很想看到这个社区 Wiki 成长为一个非常适合刚开始使用 VS 解决方案的人的资源。

Below is what I have working for me now (on my current project), however I know for a fact that there is some stuff in the wrong place. In my scenario, I'm building a Web Applicationusing MVC 2

以下是我现在对我来说有效的内容（在我当前的项目中），但是我知道有些东西放错了地方。 在我的场景中，我正在使用MVC 2构建一个Web 应用程序

Please post your idea of the ultimate solution structure so that we can get an idea of the "best way" / "best practice" (whatever that means exactly)

请发布您对最终解决方案结构的想法，以便我们了解“最佳方式”/“最佳实践”（无论这意味着什么）

IE:
How do you break up your DAL (Data-Access-Layer) / BLL (Business-Logic-Layer)?
Do you put your repository layer and service layer inside your BLL? If you're using MVC (Model-View-Controller), do you keep your controllers in the UI instead of the Core?
Do you throw lots of stuff in your Utility/Miscellaneous folders, or do you break it apart even further?
etc...

IE：
你如何分解你的 DAL（数据访问层）/BLL（业务逻辑层）？
您是否将存储库层和服务层放在 BLL 中？如果您使用 MVC（模型-视图-控制器），您是否将控制器保留在 UI 而不是核心中？
您是在 Utility/Miscellaneous 文件夹中扔了很多东西，还是将其进一步分解？
等等...

---

---

• MySolution
  • MySolution.Core
    • Authentication
      • this is where I have a POCO and a method to searialize the poco into the userData secion of the auth cookie
    • Base
      • here is where I keep my BaseController and by BaseGlobal
    • Controllers
      • all of my controllers (obviously)
    • Domain
      • DatabaseModels
        • contains my L2S .dbml file
      • JsonModels
        • models used to pass JSON objects to the veiw
      • Repositories
      • Services
      • ViewModels
    • Extensions
      • all extension methods
    • Filters
      • Action Filters
    • Utilities
      • Apis
        • all third party API code goes in here
      • Badges
        • badge calculation goes here
      • MailClient
        • send plain text or html email using the classes in here
      • RoutingHelpers
        • contains a class to enable lowercase routes
      • also contains things that I don't know where else to put... IE: HTMLSanitizer, custom HtmlHelpers,UserInfo helper (IP address, browser, etc), DataConverter, etc
  • MySolution.UI
    • App_Browsers
    • Assets
      • Css
      • Images
      • Scripts
    • Views
    • Global.asax- inherits from BaseGlobal
    • Web.config

• 我的解决方案
  • 我的解决方案核心
    • 验证
      • 这是我有一个 POCO 和一种将 poco 序列化到 auth cookie 的 userData 部分的方法
    • 根据
      • 这是我保存 BaseController 和 BaseGlobal 的地方
    • 控制器
      • 我所有的控制器（显然）
    • 领域
      • 数据库模型
        • 包含我的 L2S .dbml 文件
      • JSON 模型
        • 用于将 JSON 对象传递给 veiw 的模型
      • 存储库
      • 服务
      • 视图模型
    • 扩展
      • 所有扩展方法
    • 过滤器
      • 动作过滤器
    • 公用事业
      • 蜜蜂
        • 所有第三方 API 代码都放在这里
      • 徽章
        • 徽章计算在这里
      • 邮件客户端
        • 使用此处的类发送纯文本或 html 电子邮件
      • 路由助手
        • 包含一个类来启用小写路由
      • 还包含我不知道该放在哪里的东西... IE：HTMLSanitizer、自定义 HtmlHelpers、UserInfo helper（IP 地址、浏览器等）、DataConverter 等
  • 我的解决方案界面
    • App_Browsers
    • 资产
      • css
      • 图片
      • 脚本
    • 观看次数
    • Global.asax-继承自 BaseGlobal
    • 网页配置

---

---

Screen Shots

屏幕截图

Please feel free to comment accordingly, or better yet, post your own version (answer) below. I know that what I've got isn't the best way.

请随时发表相应的评论，或者更好的是，在下面发布您自己的版本（答案）。我知道我所拥有的并不是最好的方法。

采纳答案by Kevin Pang

Your solution/project structure looks pretty sound to me. If you've never taken a look at S#arp Architecture, you may want to. The main difference between your structure and S#arp's architecture is that S#arp's breaks out the Controllers, Services, and Repositories into separate projects. The main benefit of doing this is that it becomes easier to enforce boundaries on your dependencies (e.g. you won't accidentally access data access specific libraries from code in Core).

您的解决方案/项目结构对我来说看起来很合理。如果您从未看过S#arp Architecture，您可能想要。您的结构和 S#arp 的架构之间的主要区别在于 S#arp 的将控制器、服务和存储库分解为单独的项目。这样做的主要好处是可以更轻松地对依赖项实施边界（例如，您不会意外地从 Core 中的代码访问数据访问特定库）。

Other than that, your structure looks very similar to the one I tend to use for my projects. I also add an "Extensions" folder for extension methods, since those are sometimes hard to find a good place for.

除此之外，您的结构看起来与我倾向于用于我的项目的结构非常相似。我还为扩展方法添加了一个“扩展”文件夹，因为这些方法有时很难找到合适的位置。

回答by RPM1984

Nice Wiki.

不错的维基。

I'm starting a new project, and this is structure i have begun with.

我正在开始一个新项目，这是我已经开始的结构。

It follows the Microsoft Best Practices (Business, Data, Services, Presentation).

它遵循 Microsoft 最佳实践（业务、数据、服务、演示）。

In my solution:

在我的解决方案中：

• Business: domain/project-specific logic, and most notably POCO's.
• Data: repositories. self explanatory.
• Services: logic on top of repositories. i can add caching here, filtering, etc. My UI communicates to repository through Services, not directly to repository. (one-to-one dependency for UI).
• Presentation: MVC application (TBD).

• 业务：特定于域/项目的逻辑，最显着的是 POCO。
• 数据：存储库。不言自明。
• 服务：存储库之上的逻辑。我可以在这里添加缓存、过滤等。我的 UI 通过服务与存储库通信，而不是直接与存储库通信。（UI 的一对一依赖）。
• 演示文稿：MVC 应用程序（待定）。

You'll notice I also have a habit of prefixing the actual project assembly name with the FQN.

您会注意到我还习惯在实际项目程序集名称前加上 FQN。

I just like the look of it, plus in the Object Explorer it all looks nice and "tree-like".

我只是喜欢它的外观，而且在对象资源管理器中，它看起来很漂亮，而且“像树一样”。

Also i have a habit of putting a number in front of the folder, so it sorts according to "what needs what". In other words, everything depends on the business layer (so its on the top), repository only depends on business, services depend on repository and business, presentation depends on services and business, etc.

我也有在文件夹前面放一个数字的习惯，所以它根据“什么需要什么”进行排序。换句话说，一切都依赖于业务层（所以它在顶部），存储库只依赖于业务，服务依赖于存储库和业务，表现依赖于服务和业务等。

Of course, the above is a starting point. All i have right now is a repository which returns users, and services which apply logic on top of it (filtering).

当然，以上只是一个起点。我现在所拥有的只是一个返回用户的存储库，以及在其上应用逻辑的服务（过滤）。

Eventually i'll have more business projects, more repositories (one for each logical area of web application), more services (external API's, integration), and of course i have nothing in Presentation (im doing TDD).

最终我会有更多的业务项目、更多的存储库（一个用于 Web 应用程序的每个逻辑区域）、更多的服务（外部 API、集成），当然我在演示中没有任何内容（我在做 TDD）。

I also like having the Dependencies all in one place (project folder).

我也喜欢将依赖项集中在一个地方（项目文件夹）。

For extensions, i have one class (Extensions.cs) for each project. In other words, i am "Extending" the repository, or "Extending" the user service, or "Extending" some UI functionality.

对于扩展，我为每个项目设置了一个类 (Extensions.cs)。换句话说，我正在“扩展”存储库，或“扩展”用户服务，或“扩展”某些 UI 功能。

For test projects - i have test project per solution project.

对于测试项目 - 我有每个解决方案项目的测试项目。

That's my Two Cents (for what it's worth).

那是我的两分钱（物有所值）。

回答by David Basarab

There is room for improvement.

有改进的余地。

Any of my solutions have 4 basic parts. The UI Layer, the Business Layer, Data Access Layer, and Utilities. Each part is a project.

我的任何解决方案都有 4 个基本部分。UI 层、业务层、数据访问层和实用程序。每个部分都是一个项目。

My ultimate goal is to NEVER write code in more than one place but to reuse it.

我的最终目标是永远不要在一个以上的地方编写代码，而是要重用它。

UI and Data Access are obvious.

UI 和数据访问是显而易见的。

Anything specific to the project I am working on goes into the Business project.

我正在处理的项目的任何特定内容都会进入业务项目。

The Utilities is what I call a common library. These are good helper functions that I can use in many projects. For example a function to aid in logging.

Utilities 就是我所说的公共库。这些是我可以在许多项目中使用的很好的辅助函数。例如一个帮助记录的函数。