C# · 12月 29, 2021

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

我在一个.net c#应用程序中工作,该应用程序包含2个客户端和服务器解决方案.在服务器端有80个项目用于分隔以下建筑图层,

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

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

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

提出的解决方案是将我们的项目合并到3个领域,例如一个生产代码库,一个测试代码库和一个用于部署项目(WCF主机等)的区域,以及通过分离命名空间在同一个项目中的逻辑分层.

但是,我的担忧是

>这些分离是否可维护性好?为每个命名空间appox提供更多的hundread类.
>如果我们有共同的功能,如助手,我们在哪里放那些?

是否有其他方式来分层解决方案?

解决方法 我想你应该把逻辑层面的解决方案分开.

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

一个农场的软件你需要跟踪你的动物,蔬菜.你需要一个饲养动物的模块,一个用于将动物和蔬菜卖给消费者市场的模块.

这可以分解在以下解决方案中

后端

卖出模块:销售您的产品
>购买模块:购买种子,为您的动物食用,其他产品,…
>调度器模块:用于播种种子的触发事件,收获,…
>预测模块:预测天气下的收成数量和市场价格…
> …

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

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

前端

> ASP.NET MVC应用程序:Webshop卖给消费者
> WPF应用:批准销售
>其他WPF应用程序:购买东西.
>移动应用程序:将事件发送到手机或其他东西.
>(另一种选择是将2个或更多后端解决方案连接到1个前端解决方案)
> …

这是您的项目的一个重大变化,这将产生影响.确保你认为这是真的,如果你不要改变它.

多个解决方案将提高您的整体构建时间,重要的是要进行夜间构建,因此每个开发人员都可以随时使用最新的二进制代码,而无需在其本地机器上构建所有解决方案.

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

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

使这一切都在一起,不要弄乱二进制文件.您可以映射驱动器I.E. X:你有一个文件夹二进制文件,你有一个文件夹为每个解决方案.每个解决方案复制在后期构建事件上的程序集. (脚本这样,所以它适用于每台机器)

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

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

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

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

你也可以看看CQRS.