c# - 在单独的项目与单独的命名空间中组织代码

标签 c# .net architecture

我在 .net c# 应用程序中工作,其中包含 2 个客户端和服务器解决方案。在服务器端,有 80 多个项目用于分离以下架构层,

  • 基础设施层
  • 集成层(外部系统)
  • 领域层
  • 存储库层
  • 经理层
  • 服务层

此外,几乎每一层都有测试项目。现在,解决方案的构建时间需要 2 到 3 分钟,许多开发人员(包括我:))觉得我们需要解决这个问题。

因此,建议的解决方案是通过合并项目来减少项目的数量。在我看来,这可能是一个减少构建时间的好解决方案,我们可以实现我们想要的。

建议的解决方案是我们将我们的项目合并为 3 个区域,例如一个库用于生产代码,一个库用于测试代码,一个用于部署项目(WCF 主机等),并通过分离命名空间。

不过,我担心的是

  1. 这些分离是否有利于可维护性?为大约每个命名空间提供更多的类。
  2. 如果我们有通用功能,例如助手,我们应该把它们放在哪里?

还有其他方法可以对解决方案进行分层吗?

最佳答案

我猜你应该将你的解决方案拆分成逻辑层。

作为你把助手放在哪里的一部分。在最低级别之一为其制定解决方案。

示例

农场软件。你需要跟踪你的动物、蔬菜。您需要一个用于喂养动物的模块和一个用于向消费者市场销售动物和蔬菜的模块。

这可以分为以下解决方案

后端

  • 销售模块:销售您的产品的一切
  • 购买模块:购买种子、动物食物、其他产品……
  • Sheduler 模块:播种、收获等的触发事件......
  • 预测模块:根据天气和市场价格预测收获量,......
  • ...

这些后端模块中的每一个都可以拥有自己的数据访问层、DTO、WCF 服务......

此解决方案将仅包含业务逻辑、数据访问...。并且可以有多个前端解决方案连接到这些后端解决方案。

前端

  • ASP.NET MVC 应用程序:用于向消费者销售的网上商店
  • WPF 应用程序:批准销售
  • 其他 WPF 应用程序:买东西。
  • 移动应用程序:将事件发送到您的手机或其他设备。
  • (另一种选择是将 2 个或更多后端解决方案连接到 1 个前端解决方案中)
  • ...

这对您的项目来说是一个巨大的变化,并且会产生影响。如果你不想改变它,请确保你认为这是真的。

多个解决方案会增加您的整体构建时间,每晚构建一次非常重要,这样每个开发人员都可以始终使用最新的二进制文件,而不必在本地计算机上构建所有解决方案。

请注意,您仍然可以在不同的解决方案中使用图层:

  • 基础设施层
  • 集成层(外部系统)
  • 领域层
  • 存储库层
  • 经理层
  • 服务层

为了让这一切一起工作,不要被二进制文件弄乱。您可以映射驱动器 I.E. X:你有一个文件夹二进制文件,每个解决方案都有一个文件夹。每个解决方案在生成后事件中复制程序集。 (编写脚本,因此它适用于每台机器)

如果你有良好的网络基础设施,你也可以将其复制到服务器上。因此,当您在 TFS 中构建所有解决方案时,它可以将其复制到所有开发人员都可以访问的位置。

如果您在 TFS 中构建,请确保您的构建顺序是正确的,首先是最低层,最后是最高层。

但是当您拆分解决方案时,在解决方案中您可能不需要在每个解决方案中都需要它们。

我最近读了一篇关于 Onion Architecture 的文章,也许你也可以看看那个。 (它特定于 ASP.NET MVC)。

您还可以查看 CQRS .

关于c# - 在单独的项目与单独的命名空间中组织代码,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/12968341/

相关文章:

.net - 使用linq2xml订购xml文件

c# - EF Code First DropCreateDatabase始终不执行

c# - 如何使用C#将QTP结果自动导出为PDF

c# - 确保语句未优化 "away"

c# - 为什么 C# 中的异步调用需要这样声明,如果它们所在的方法已经用 'async' 关键字声明了?

c# - 使用接口(interface)实现 CRUD

database - 设计 : Business Logic or Data Storage on data manipulation during loads

javascript - 将值从 JsonResult 方法传递到另一个方法

c# - OrmLite.SqlServer 程序集出错

c# - .NET 的类似 Resque 技术