>基础设施层
>集成层(外部系统)
>域层
>存储库层
>管理层
>服务层
另外几乎每个层都有测试项目.现在,解决方案的构建时间需要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.
