visual-studio .NET 解决方案 - 多个项目与一个项目

.NET solution - many projects vs one project

提问by Mike Q

We currently have a rapidly growing C# codebase. Currently we have about 10 projects, split up in the usual categories, common/util stuff, network layer, database, ui components/controls etc.

我们目前有一个快速增长的 C# 代码库。目前我们有大约 10 个项目，分为通常的类别、通用/实用工具、网络层、数据库、ui 组件/控件等。

We run into the occasional circular dependency where project x depends on something in y and vice-versa. We are looking at maybe collapsing the projects down to one and just managing using structure folders/namespaces. We have a Java project which of course organises just using folders/packages so we're not sure what, if any, benefit having multiple projects brings. None of our projects require special project properties, except the main run project, which we may kept separate (and very thin).

我们偶尔会遇到循环依赖，其中项目 x 依赖于 y 中的某些内容，反之亦然。我们正在考虑将项目合并为一个项目，并仅使用结构文件夹/命名空间进行管理。我们有一个 Java 项目，它当然只使用文件夹/包进行组织，所以我们不确定拥有多个项目会带来什么好处（如果有的话）。我们的项目都不需要特殊的项目属性，除了主运行项目，我们可以将它们分开（并且非常薄）。

Does anyone have any prior experience in why one project is better/worse than multiple projects and could suggest the best approach? And also any issues with circular dependencies would be useful in either approach would be useful.

有没有人有任何关于为什么一个项目比多个项目更好/更差的经验并且可以提出最佳方法？而且任何循环依赖的问题在任何一种方法中都是有用的。

Any input appreciated.

任何输入表示赞赏。

回答by Jon Seigel

If you've got projects with circular dependencies, that indicates a problem with the design of the code, not with the solution/project model.

如果您的项目具有循环依赖项，则表明代码设计存在问题，而不是解决方案/项目模型。

回答by Heinzi

In my experience, separating code which creates a singleexecutable in multipleprojects can be useful if you want to

根据我的经验，如果您想将在多个项目中创建单个可执行文件的代码分开可能会很有用

• use different programming languages in different parts,
• develop libraries that are also used by other applications, or
• conceptually separate multiple layers (i.e., let Visual Studio ensure that there are no direct references from project Libto project App).

• 在不同的部分使用不同的编程语言，
• 开发其他应用程序也使用的库，或
• 从概念上分离多个层（即，让 Visual Studio 确保没有从项目Lib到项目App 的直接引用）。

Personally, I base most of my decisions on the second point. Do I think that part of the application can be a more general library that I am likely to need in other application? Put it in a separate project. Otherwise, as you point out, having a single project usually makes development easier.

就我个人而言，我的大部分决定都是基于第二点。我认为应用程序的那部分可以是我在其他应用程序中可能需要的更通用的库吗？把它放在一个单独的项目中。否则，正如您所指出的，拥有一个项目通常会使开发更容易。

About the circular dependencies: The recommended way to solve this is to put interfacesof the referenced stuff into a third project. For example, if you have two applications both sharing some objects through remoting, you put interfaces of the shared objects in a library project to ensure that they are available to both applications.

关于循环依赖：推荐的解决方法是将引用的东西的接口放到第三个项目中。例如，如果您有两个应用程序都通过远程处理共享某些对象，则将共享对象的接口放在库项目中以确保它们对两个应用程序都可用。

Without knowing the exact design of your application, it's difficult to give more concrete advise.

在不知道您的应用程序的确切设计的情况下，很难给出更具体的建议。

回答by Neil N

When making dependencies between projects, it helps to always think of one as "Lower" and the other as "Higher"

在项目之间建立依赖关系时，始终将一个视为“较低”而将另一个视为“较高”会有所帮助

A higher level project (such as a web interface) should only depend on lower projects. A lower project (such as a utility) should never depend on something higher, such as a web interface. If this happens, it either means your higher level project has something that really should be in the lower project, or vice versa.

更高级别的项目（例如 Web 界面）应该只依赖于较低级别的项目。较低的项目（例如实用程序）不应依赖于较高的项目，例如 Web 界面。如果发生这种情况，要么意味着您的较高级别的项目确实应该在较低的项目中包含某些内容，反之亦然。

回答by Juri

Generally speaking, having multiple VS projects (within a VS solution) does just make sense in these cases

一般来说，在这些情况下，拥有多个 VS 项目（在 VS 解决方案中）确实有意义

• You can potentially reuse the produced DLL in another project (a class library)
• You want to separate things like in a layered architecture where you may drop the DAO dll and exchange it with another
• There are just different front-end projects (i.e. ASP.net MVC apps) which need to be deployed in different physical locations but use the same BL, DAL.

• 您可以潜在地在另一个项目（类库）中重用生成的 DLL
• 您想在分层架构中分离事物，您可以在其中删除 DAO dll 并将其与另一个
• 只是有不同的前端项目（即 ASP.net MVC 应用程序）需要部署在不同的物理位置但使用相同的 BL、DAL。

If your saying you're having the problem of circular dependencies, then you're having a problem in your code design. Probably you may put that logic which is used by multiple projects inside a class library designed to be reused in many projects.

如果你说你有循环依赖的问题，那么你的代码设计就有问题。可能您可能会将多个项目使用的逻辑放在旨在在许多项目中重用的类库中。

Generally I'd say you shouldn't add more projects if you don't really need it. Splitting up into projects means adding more complexity, so when you're doing so, you should gain a reasonable benefit from it.

一般来说，我会说如果你真的不需要它，你不应该添加更多的项目。拆分为项目意味着增加更多的复杂性，因此当您这样做时，您应该从中获得合理的收益。

回答by Rob Walker

We've noticed that Visual Studio's performance degrades significantly as the number of projects grows. Something as simple as switching from 'Debug' to 'Release' configurations can takes upwards of 15 seconds for solutions with around a dozen C# projects in them.

我们注意到，随着项目数量的增加，Visual Studio 的性能显着下降。对于包含大约十几个 C# 项目的解决方案，从“调试”配置切换到“发布”配置这样简单的事情可能需要 15 秒以上的时间。

Also, as a counter point to Reed's comment about build times, I've seen build times grow because Visual Studio seems to be spending a lot of time on the project overhead. The actual compile times seem fast, but the total time from hitting build to being able to run is significant.

此外，作为 Reed 对构建时间的评论的反驳，我看到构建时间在增长，因为 Visual Studio 似乎在项目开销上花费了大量时间。实际编译时间似乎很快，但从构建到能够运行的总时间很长。

My advice would be keep the number of projects to the minimum you can get away with. If you need multiple projects for good reasons then use them as necessary, but prefer to keep things together. You can also refactor to split a project into two if necessary.

我的建议是将项目数量保持在您可以逃脱的最低限度。如果您有充分的理由需要多个项目，请根据需要使用它们，但更愿意将它们放在一起。如有必要，您还可以重构以将项目一分为二。

回答by Owen

There are several reasons for separating a solution into different projects (and thus assemblies), and it mainly comes down to re-usability and separation of responsibilities.

将解决方案分成不同的项目（以及程序集）有几个原因，主要归结为可重用性和职责分离。

Now your goal should be to make an assembly (aka project) has the minimum amount of dependencies on other assemblies in your solution, otherwise you may as well have everything in fewer assemblies. If for example your UI components have a strong dependency on your data access code then there is probablysomething wrong.

现在，您的目标应该是使程序集（又名项目）对解决方案中其他程序集的依赖最少，否则您也可以在更少的程序集中拥有所有内容。例如，如果您的 UI 组件对您的数据访问代码有很强的依赖性，那么可能有问题。

Really, this comes down to programming against common interfaces.

实际上，这归结为针对通用接口的编程。

Note However:

但是请注意：

When I say "otherwise you may as well have everything in fewer assemblies", I wasn't necessarily suggesting this is the wrong thing to do. In order to achieve true separation of concerns your going to be writing a lot more code and having to think about your design a lot more. All this extra work may not be very beneficial to you, so think about it carefully.

当我说“否则你也可以在更少的程序集中拥有所有东西”时，我不一定暗示这是错误的做法。为了实现真正的关注点分离，您将需要编写更多代码，并且必须更多地考虑您的设计。所有这些额外的工作对你来说可能不是很有好处，所以仔细考虑一下。

回答by Stacy Vicknair

You might find the following Martin article worthwhile: Design Principles and Design Patterns (PDF)(Java).

您可能会发现以下 Martin 文章很有价值：设计原则和设计模式 (PDF)(Java)。

A revised version in C# specifically is available in Agile Principles, Patterns, and Practices in C#also by Martin.

Martin 还专门在 C# 中的敏捷原则、模式和实践中提供了 C# 中的修订版本。

Both express different guidelines that will help you decide what belongs where. As pointed out, however, cyclic dependencies indicate that there are either problems with design or that something is in a component that belongs in a different one.

两者都表达了不同的指导方针，可以帮助您决定什么属于哪里。然而，正如所指出的，循环依赖表明设计存在问题，或者某个组件中的某些内容属于不同的组件。

回答by Reed Copsey

Multiple projects allows better reuse of specific types within multiple applications. It can also improve build time, since certain projects will not need to be rebuilt for all code changes.

多个项目允许在多个应用程序中更好地重用特定类型。它还可以缩短构建时间，因为不需要为所有代码更改重新构建某些项目。

A single project makes life easier, since you don't have to worry about dependencies. Just realize that the ease comes at a cost - it also makes it easier to let poor design decisions creep into the code base. Circular dependencies, whether in one project or multiple, are typically a design flaw, not a requirement.

单个项目使生活更轻松，因为您不必担心依赖项。只要意识到轻松是有代价的——它也更容易让糟糕的设计决策渗透到代码库中。循环依赖，无论是在一个项目中还是在多个项目中，通常是一种设计缺陷，而不是一种要求。

回答by Shad

Where I work, we opted for an approach where the aim is to have a single project per solution. All code library projects also have a test harness application and/or a unit test app.

在我工作的地方，我们选择了一种方法，其目标是每个解决方案都有一个项目。所有代码库项目还有一个测试工具应用程序和/或单元测试应用程序。

As long as the code libraries pass testing, the release versions (with Xml Documentation file of course) get transferred into a “Live” folder.

只要代码库通过测试，发布版本（当然还有 Xml 文档文件）就会转移到“Live”文件夹中。

Any projects that requires functionality from these other projects have to reference them from the “Live” folder.

任何需要这些其他项目功能的项目都必须从“Live”文件夹中引用它们。

The advantages are pretty clear. Any project always accesses known working code. There is never a chance of referencing a work in progress assembly. Code gets tested per assembly, making it far easier to understand where a bug originates. Smaller solutions are easier to manage.

优势非常明显。任何项目总是访问已知的工作代码。永远没有机会引用正在进行的程序集。每个程序集都会对代码进行测试，从而更容易理解错误的来源。更小的解决方案更易于管理。

Hope this helps!

希望这可以帮助！

Shad

鲱鱼

回答by lubos hasko

Start with single project. The only benefit in splitting your codebase into more projects is simply to improve build time.

从单个项目开始。将代码库拆分为更多项目的唯一好处就是缩短构建时间。

When I have some reusable functionality that I really want to isolate from main project, I'll just start brand new solution for it.

当我有一些我真的想从主项目中分离出来的可重用功能时，我会为它开始全新的解决方案。