终极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 searial到auth cookie的userData secion的地方
    • 基础
      • 这是我保留BaseController和BaseGlobal的地方
    • 控制器
      • 我的所有控制器(显然)
    • 域
      • DatabaseModels
        • 包含我的L2S .dbml文件
      • JsonModels
        • 用于将JSON对象传递给视图的模型
      • 库
      • 服务
      • 的ViewModels
    • 扩展
      • 所有扩展方法
    • 过滤器
      • 动作过滤器
    • 公用事业
      • 蜜蜂
        • 所有第三方API代码都在这里
      • 徽章
        • 徽章计算在这里
      • 的MailClient
        • 使用此处的课程发送纯文本或HTML电子邮件
      • RoutingHelpers
        • 包含一个用于启用小写路由的类
      • 还包含我不知道还放在哪里的东西... IE:HTMLSanitizer,自定义HtmlHelpers,UserInfo助手(IP地址,浏览器等),DataConverter等
  • MySolution.UI
    • App_Browsers文件
    • 资产
      • CSS
      • 图片
      • 脚本
    • 查看
    • Global.asax - 继承自BaseGlobal
    • Web.config文件

---

屏幕截图

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

Answer 1

不错的维基.

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

它遵循Microsoft最佳实践(业务,数据,服务,演示).

在我的解决方案:

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

您会注意到我还习惯使用FQN为实际项目程序集名称添加前缀.

我只是喜欢它的外观,加上在对象资源管理器中它看起来很漂亮和"树状".

另外我习惯在文件夹前放一个数字,所以根据"什么需要什么"进行排序.换句话说,一切都取决于业务层(因此它位于顶层),存储库仅依赖于业务,服务依赖于存储库和业务,表示依赖于服务和业务等.

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

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

我也喜欢在一个地方(项目文件夹)中使用Dependencies.

对于扩展,我为每个项目都有一个类(Extensions.cs).换句话说,我正在"扩展"存储库,或"扩展"用户服务,或"扩展"某些UI功能.

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

这是我的两分钱(因为它的价值).

Answer 2

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

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

Answer 3

还有改进的余地.

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

我的最终目标是永远不要在不止一个地方编写代码,而是重用它.

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

我正在处理的项目的任何特定内容都会进入Business项目.

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