我们在很好地组织解决方案时遇到了很多麻烦。我们有多个应用程序。他们是类似的应用程序,所以很多重用都完成了。不同的应用包含不同的功能,具体取决于我们不同的客户将支付的费用如何为多个应用程序组织.NET解决方案,项目和系统文件夹?
那么,我们该如何组织事情呢? MSDN说,在下面的方式来组织:
SolutionFolder\
Proj1Folder\
Proj2Folder\
Proj3Folder\ ...
(注:解决方案文件夹,我的意思是系统,而不是一个Visual Studio解决方案文件夹中的实际文件夹。)
但没有提到任何细节有关多重解决方案,重用项目。在第一个解决方案文件夹下创建第二个解决方案文件夹和参考项目是没有意义的。我的第一个想法是完全隔离解决方案,然后根据需要参考项目。那有意义吗?见下:
Solutions\
Solution1.sln
Solution2.sln
Solution3.sln
Projects\
AFeatures\
AProject1\
AProject2\
AProject3\
BFeatures\
BProject1\
BProject2\
CFeatures\
CProject1\
CProject2\
在上面的例子中,我已经基于某些功能分组项目。解决方案1可能包含功能A和C,解决方案2可能包含功能B和C,解决方案3可能包括A和B.事情变得更加复杂,因为每个功能都可能具有不属于所有解决方案的子功能。换句话说,可能有共同的AF特征,但是更具体的A-1特征,A-2特征等。
最重要的是,我们还想将我们的项目组织在基于n层架构的基础上。所以,我想我们会在中间添加BusinessServices,DataServices和UserServices文件夹。但是,将n层文件夹放在特征结构的上方还是下方是否有意义?这是我的大脑开始旋转的地方。
在类似的说明中,我们希望在不同的项目中实现我们的接口。这可能不是什么大问题。我想我们会在同一目录级别上有一个AInterfacesProject1和AProject,因此它们靠得很近。
我会很感激任何人对我的例子的评论。而且,如果您对我的同一问题有过经验,我会很好奇你是如何组织它的。