如何在.Net中创建创建分区解决方案 [英] How do I create Create a Partitioned Solution in .Net

问题描述

我们正在为业务开发一个新的.NET系统。系统将为用户管理多个MVC应用程序，并管理后端的若干服务。看起来像这样



前端：

竞价

成本核算

送货

将来扩展。



后端：

买入价API

成本API

运输API

用于管理解决方案中特定任务的其他服务。



现在我们为整个系统提供单一解决方案。我在想，随着这种增长，它将变得太大而无法有效管理。作为当前解决方案评估的一部分，我们正在考虑分区解决方案。我在MSDN之外没有任何运气，看看它是如何工作的。 MSDN网站已弃用该文档。



有没有人使用分区解决方案设置大型应用程序系统？



使用单一.NET解决方案创建整个业务系统的经验是什么？



管理应用系统代码的最佳方法是什么？

We are developing a new .NET system for the business. The system will manage several MVC applications for the users and several services to manage the back end. It will look like this

Front End:
Bidding
Costing
Shipping
To expand in the future.

Back End:
Bid API
Cost API
Shipping API
other services to manage specific tasks in the solution.

Right now we have a single solution for the entire system. I am thinking as this grows, it will become too large to manage efficiently. As part of the evaluation of the current solution, we are considering partitioned solutions. I have not had any luck, outside of MSDN, to see how it works. The MSDN site has deprecated the document.

Has anyone out there set up a large system of applications using partitioned solutions?

What experience has anyone had creating an entire business system using a single .NET solution?

What is the best way to manage the code for a system of applications?

推荐答案

请参阅我对这个问题的评论。



我无法清楚地看到MSDN网站已弃用该文档中的文件是什么意思。也许，这个适合你：

https://msdn.microsoft .com / zh-CN / library / ee817674.aspx [ ^ ]。



但坦率地说，你真的不需要这样的文件。 （请再次查看我的评论，签名之前的最后一节，我解释了真正迫切需要的内容:-)。）您只需要了解MSBuild如何工作并理解项目增长，决策，重构和复杂性控制。至于MSBuild，您可以全部学习：

https：// msdn。 microsoft.com/en-us/library/dd637714.aspx [ ^ ]，

https：// msdn.microsoft.com/en-us/library/0k6kkbsd.aspx [ ^ ]。



如果你全部分析，你会看到你可以选择开发自己的项目类型，真正需要的是，开发和支持不同的构建工具（特别是，确保它们在使用之前构建，所有构建技术都是关于它的：依赖项，时间戳，构建使用的声明性定义以及自动确定的操作顺序）。您可以拥有可以将项目作为其成员的主项目，但也可以使用其他解决方案，这对于单独开发的图层非常有用。



我必须注意到许多人错误地评估与解决方案相关的角色和可能性首先，您需要对所有内容进行一次单击构建，迭代并完全重新构建。此外，您还需要一种版本增量，部署等机制。重要的是不要将它们混合在一起。为此，解决方案可以工作，但它也可以是一些主项目。对于每个此类操作而言，为项目的所有组件设置一个批次非常重要。



但这不是解决方案的唯一作用。解决方案也可以是开发人员的实体，这是项目集的一个观点（在构建所有项目的能力方面应该是一个完整的子集，而不是依赖于缺少的组件。）你可以分开解决方案只是为了让一些开发人员能够在产品的一部分工作，而不是看到其他项目。在开发的其他一个阶段，可以放弃此解决方案并创建其他解决方案。因此，您可能希望有两种不同类型的解决方案：用于开发的部分解决方案，以及用于总体构建的解决方案。您将决定它应该只是一个解决方案，还是由一些主项目联合起来的一组解决方案。您的目标是确保您拥有一个全球产品构建作为点击工件。



最后，您需要制定战略中最重要的部分：能力推迟决定。良好的架构不是仅基于良好正确决策的架构。真正优秀的架构是您可以以较低的成本推出决策并修复错误决策的架构。现在不要决定如何构建不断增长的产品以实现更好的可管理性。不要走这条路。相反，草拟策略，以便您可以在以后更好地了解产品和项目的增长方式时做出这些决策。这不合逻辑吗？

-SA

Please see my comment to the question.

I cannot clearly see what do you mean by the document in "MSDN site has deprecated the document". Maybe, this one will work for you:
https://msdn.microsoft.com/en-us/library/ee817674.aspx[^].

But frankly, you don't really need such document. (Please see my comment again, last clause before the signature where I explain what's really critically needed :-).) You only need to understand how MSBuild work and have understanding of project growth, decision-making, refactoring and complexity control. As to MSBuild, you can learn it all:
https://msdn.microsoft.com/en-us/library/dd637714.aspx[^],
https://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx[^].

If you analyze it all, you will see that you can choose to develop your own project types, which can really be needed, to develop and support different build tools (in particular, make sure they are build before you use them, all build technologies are about it: dependencies, time stamps, declarative definitions used by build and automatically determined order of operations). You can have master projects which can have projects as their members, but, alternatively, other solutions, which can be useful for having separately developed layers.

I must note that many incorrectly evaluate the roles and possibilities related to solution. First of all, you need to have some one-click build of everything, iterative and complete re-build. Also, you need a mechanism for version increments, deployment, and more. It's important not to mix it all together. For this purposes, a solution can work, but it could also be some master project. It's just important to have one single batch for all components of the project for each of such operations.

But this is not the only role of solution. The solution could also be a developer's entity, which is a point of view at the set of project (which should be a complete sub-set, in terms of ability to build it all, not depending on missing components.) You can have separate solutions just to allow some developer to work at the part of the product, not seeing other projects. On some other stage of development, this solution can be set aside and other solution created. So, you may want to have two different classes of solutions: partial solutions used for development, and the solutions used for total build. You will decide if it should be only one solution, or a set of solutions united by some master project. Your goal is to make sure you have one global product build as on-click artifact.

And finally, you need to develop most important part of the strategy: the ability to post-pone the decision. Good architecture is not the one which is based only good correct decisions. Really good architecture is the one where you can post-pone the decisions and fix your bad decision at lower costs. Don't decide how you structure your growing product for better manageability now. Don' go this way. Instead, sketch the strategy which allows you to make those decisions later, when you can better see the ways the product and your projects grow. Isn't that logical?

—SA

这篇关于如何在.Net中创建创建分区解决方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！