终极Visual Studio解决方案结构

Question

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

请随时编辑此内容，评论您认为可能不正确的内容，建议替代方案等。我很高兴看到这个社区Wiki成为刚开始使用VS Solutions的人们的一个很好的资源。

以下是我现在为我工作的（在我目前的项目中），但我知道有一些事情在错误的地方。 在我的方案中，我正在使用 MVC 2构建 Web应用程序

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

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

---

  

  
• 的 MySolution      
    
  • 的 MySolution.Core      
      
    • 的验证      
        
      • 这是我有一个POCO和一个将poco分类到auth cookie的userData部分的方法
        
      
    • 的基      
        
      • 这里是我保留BaseController和BaseGlobal
      的地方   
      
    • 的控制器      
        
      • 我的所有控制器（显然）
        
      
    • 的域      
        
      • 的 DatabaseModels      
          
        • 包含我的L2S .dbml文件
          
        
      • 的 JsonModels      
          
        • 用于将JSON对象传递给veiw的模型
          
        
      • 的存储库
        
      • 的服务
        
      • 的的ViewModels
        
      
    • 的扩展程序      
        
      • 所有扩展方法
        
      
    • 过滤器      
        
      • 动作过滤器
        
      
    • 实用程序      
        
      • 的蜜蜂      
          
        • 所有第三方API代码都在这里
          
        
      • 的徽章      
          
        • 徽章计算到此处
          
        
      • 的的MailClient      
          
        • 使用此处的课程
        发送纯文本或html电子邮件   
        
      • 的 RoutingHelpers      
          
        • 包含一个启用小写路由的类
          
        
      • 还包含我不知道还放在哪里的内容...... IE：HTMLSanitizer，自定义HtmlHelpers，UserInfo助手（IP地址，浏览器等），DataConverter等
        
      
    
  • 的 MySolution.UI      
      
    • App_Browsers
      
    • 的资产      
        
      • Css
        
      • 图片
        
      • 脚本
        
      
    • 的浏览
      
    • Global.asax - 继承自BaseGlobal
      
    • 的的Web.config
      
    
  

---

屏幕截图

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

Answer 1

Nice Wiki。

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

遵循Microsoft最佳业务实践（业务，数据，服务，演示文稿）。

在我的解决方案中：

• 业务：域/项目特定逻辑，最值得注意的是POCO。
• 数据：存储库。自我解释。
• 服务：存储库之上的逻辑。我可以在这里添加缓存，过滤等。我的UI通过服务与存储库进行通信，而不是直接与存储库进行通信。 （UI的一对一依赖关系）。
• 演示文稿：MVC应用程序（TBD）。

你会注意到我也习惯用FQN作为实际项目程序集名称的前缀。

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

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

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

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

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

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

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

这是我的两分钱（因为它的价值）。

Answer 2

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

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

Answer 3

还有改进的余地。

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

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

UI和数据访问显而易见。

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

公用事业是我称之为公共图书馆。这些是我可以在许多项目中使用的好帮手函数。例如，一个帮助记录的功能。