logo标签列表

Visual Studio 终极解决方案结构

.netvisual-studioprojects-and-solutions
53

考虑到这可能因项目而异，我正在寻找“最佳实践”方法来构建VS（Visual Studio）解决方案。

请随意编辑此内容，指出您认为可能不正确的内容，提供替代方案等。我希望看到这个社区百科全书成为初学者入门VS Solutions的重要资源。

以下是当前项目中适用于我的结构（Web应用程序，MVC 2），但我知道确实有一些放错了位置。

请发表您对最终解决方案结构的想法，以便我们了解“最佳方式”/“最佳实践”的概念。

例如：
您如何分离DAL（数据访问层）/ BLL（业务逻辑层）？
您是否将存储库层和服务层放在BLL内部？
如果您使用MVC（模型-视图-控制器），您是否将控制器保留在UI中而非核心代码中？
您是否将大量内容放在Utility/Miscellaneous文件夹中，还是进一步拆分？
等等...

 
     
  • MySolution      
       
    • MySolution.Core    
         
      • Authentication    
           
        • 这里我有一个POCO和将poco序列化到auth cookie的方法
          •  
        •  
      • Base    
           
        • 这里是我保存BaseController和BaseGlobal的位置
          •  
        •  
      • Controllers    
           
        • 所有的控制器（显然）
          •  
        •  
      • Domain    
        • 数据库模型(Database Models)
          • 包含我的L2S .dbml文件
        • Json模型(Json Models)
          • 用于向视图传递JSON对象的模型
        • Repositories(仓库)
        • Services(服务)
        • ViewModels(视图模型)
      • Extensions(扩展)
        • 所有的扩展方法都在这里
      • Filters(过滤器)
        • Action Filters(操作过滤器)
      • Utilities(实用工具)
        • Api(应用程序接口)
          • 所有第三方API代码都放在这里
        • Badges(徽章)
          • 徽章计算放在这里
        • MailClient(邮件客户端)
          • 使用此处的类发送纯文本或HTML邮件
        • RoutingHelpers(路由助手)
          • 包含一个启用小写路由的类
        • 还包括我不知道放在哪里的东西...即：HTMLSanitizer，自定义HtmlHelpers，UserInfo helper（IP地址，浏览器等），DataConverter等
    • MySolution.UI
      • App_Browsers(应用程序浏览器)
      • Assets(资源)
        • Css(层叠样式表)
        • 图片
        • 脚本
      • 视图
      • Global.asax - 继承自BaseGlobal
      • Web.config

屏幕截图
核心用户界面

请随意提出评论，或者更好的是，在下面发布您自己的版本（答案）。我知道我所拥有的不是最好的方式。

3
我觉得应该标记一下，以显示这是特定于网络应用程序的。 - Kevin Crowell
我曾在我的情况中说过，“我正在使用MVC 2构建Web应用程序”，但我仍然非常感兴趣其他应用程序，例如Web表单、MVP、Win表单等等。一般原则“应该”仍然适用，至少我认为是这样的。 - Chase Florell
2
这里没有太多的解决方案结构 - 我有一个大约有60个项目的应用程序;) 这需要解决方案结构。你主要有项目内部结构;) - TomTom
1
嗯，我不确定我个人是否会将60多个项目放在一个解决方案中。我认为我会将其分解一些以保持理智。 - Chase Florell
我的项目还有另一个MVC应用程序用于API，我没有展示。我更关心的是核心项目的细节和实现。 - Chase Florell
我注意到这个问题和答案存在的一个问题是，它没有解释一些使用的术语和概念，如POCO、Core、L2S/DBML、TBD等。这种缺乏澄清使其对新手不太有用。 - carloswm85
3个回答
11

很好的Wiki。

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

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

alt文本

在我的解决方案中：

  • 业务：特定于领域/项目的逻辑，尤其是POCO。
  • 数据：存储库。不言自明。
  • 服务：存储库顶部的逻辑。我可以在此处添加缓存、过滤等功能。我的UI通过Services与存储库通信，而不是直接与存储库通信（UI有一对一的依赖关系）。
  • 演示：MVC应用程序（待定）。

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

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

此外，我有一个习惯，在文件夹前面放置一个数字，以便根据“需要什么”进行排序。换句话说，一切都依赖于业务层（因此在顶部），存储库仅依赖于业务，服务依赖于存储库和业务，演示依赖于服务和业务等。

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

最终，我将拥有更多的业务项目、更多的存储库（每个网络应用程序的逻辑区域都有一个），更多的服务（外部API、集成），当然，我的演示中什么都没有（我正在进行TDD）。

我还喜欢将所有依赖关系放在一个地方（项目文件夹）。

对于扩展，我为每个项目都有一个类（Extensions.cs）。换句话说，我正在“扩展”存储库，或者“扩展”用户服务，或者“扩展”一些UI功能。

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

那是我的想法（值得多少钱）。

我真的很喜欢这个，但有一个概念让我无法理解。以以下为例UI/Controller -> Service -> Repository -> L2S/DBML如果我的User Poco是由L2S类生成的，并且我需要将该对象从控制器传递到服务，则我需要在控制器中包含L2S类，这反过来又违背了分离项目的目的...是这样吗还是我漏了什么？-或者我在业务模型中创建一个相同的POCO，可以在控制器和服务之间传递。 - Chase Florell
POCO baby POCO. =) 这就是我的商业模式，EF将表映射到我的自定义POCO中，然后在应用程序中传递它们。不过如果没有POCO，你说得对。如果我不使用POCO（我讨厌这个词，但我无法停止使用它），我可以重新思考架构。此外，我不再使用L2SQL - 完全使用EF。 - RPM1984
我一直在看EF，但我认为它只是L2S的一些高级功能。 EF仍然会创建您的POCO对象......所以你的意思是在你的业务模型中第二次创建相同的POCO对象吗？ - Chase Florell
@rockinthesixstring - 不行。默认情况下，EF会为您创建POCO，放在一个名为<ModelName>.edmx.designer.cs的隐藏类中。这是EF“代码生成”的一部分。但是，我关闭了此功能。因此，EF什么也不做。您可以将表拖放到EDM上，而不会创建设计文件-您需要手动创建自己的映射（并不像听起来那么难）。因此，实际上，您可以“接管”POCO生成过程，以便将其放置在所需位置并应用特定行为。L2SQL适合“拖放即可”，但它缺少像EF / NHibernate这样成熟ORM的功能（在我看来）。 - RPM1984
“Custom POCO's”任务使用VS2010 T4 POCO生成器变得更加容易，但这仍然只能生成一个文件（.tt）。即便如此，我仍然使用它，然后将代码复制并粘贴到我的自定义类中——这样可以避免手动映射数据库列到POCO属性时出现的错误。 - RPM1984
9

还有改进的空间。

我的解决方案包括四个基本部分：UI层、业务层、数据访问层和实用工具。每个部分都是一个项目。

我的终极目标是永远不要在多个地方编写代码，而是重复使用它。

UI和数据访问很明显。

任何特定于我正在处理的项目的内容都放在业务项目中。

实用工具是我称之为公共库的东西。这些是好的辅助函数，我可以在许多项目中使用，例如帮助记录日志的函数。

你把扩展方法放在实用工具项目还是业务项目中？ - Chase Florell
5
始终有改进的空间。 - Karsten
7
您的解决方案/项目结构看起来非常合理。如果您从未查看过S＃arp Architecture，建议您查看一下。您的结构与S＃arp的架构主要区别在于，S＃arp将控制器（Controllers），服务（Services）和存储库（Repositories）分为单独的项目。这样做的主要好处是更容易强制执行依赖关系的边界（例如，您不会意外地从核心代码访问数据访问特定库）。
除此之外，您的结构看起来非常类似于我通常用于我的项目的结构。我还添加了一个“Extensions”文件夹以用于扩展方法，因为有时很难找到一个好的位置。
1
你的 Extensions 文件夹是在你的 Core 项目中，还是放在一个更加“实用”的项目中，以便在其他项目中重复使用？ - Chase Florell
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接