将项目拆分为多个项目的原因？
将一个开发项目（例如 ASP.NET MVC 应用程序）拆分为多个项目的常见原因有哪些？代码组织也可以通过文件夹来完成。多个项目往往会产生循环引用冲突，并因必须管理/解决这些冲突而增加复杂性。
那么，为什么呢？
What are common reasons to split a development project (e.g. ASP.NET MVC application) into multiple projects? Code organization can be done via folders just as well. Multiple projects tend to generate circular reference conflicts and increase complexity by having to manage/resolve those.
So, why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
代码重用。假设您有项目 A，并且启动了一个新项目 B，该项目具有许多与项目 A 相同的功能。将 A 的共享部分拉出并将它们制作成一个可供 A 和 B 共同使用的库是有意义的这允许您在两个地方都拥有代码，而不必在两个地方维护相同的代码。
代码重用，倒置。假设您有一个在一个平台上运行的项目。现在您希望它在两个平台上运行。如果您可以分离出与平台相关的代码，则可以为每个与平台相关的库启动不同的项目，然后使用针对不同平台的不同库来编译您的中央代码库。
Code reuse. Let's say you have project A and you start a new project B which has many of the same functions as project A. It makes sense to pull out the shared parts of A and make them into a library which can be used by both A and B. This allows you to have the code in both without having to maintain the same code in two places.
Code reuse, inverted. Let's say you have a project which works on one platform. Now you want it to work on two platforms. If you can separate out the platform-dependent code, you can start different projects for each platform-dependent library and then compile your central codebase with different libraries for different platforms.
有关将项目拆分为多个项目的一些提示：
将项目拆分为多个类库的原因之一是可重用性。我还没有看到应用程序的 BLL 或 DAL 部分在另一个应用程序中重复使用。这是九十年代教科书告诉我们的！但大多数（如果不是全部）现代应用程序都过于具体，即使在同一企业中，我也从未见过在多个应用程序中重复使用相同的 BLL 或 DAL 部分。大多数时候，这些类库中的内容纯粹是为了服务于用户在特定应用程序中看到的内容，并且它不是可以轻松重用的东西（如果有的话）。
将项目分成多个类库的另一个原因是可部署性。如果您想独立版本化和部署这些部分，那么走这条路确实有意义。但这通常是框架的用例，而不是企业应用程序的用例。实体框架就是一个很好的例子。它由多个程序集组成，每个程序集专注于不同的功能领域。我们有一个包含主要工件的核心程序集，我们有另一个用于与 SQL Server 数据库通信的程序集，另一个用于 SQLite 的程序集，等等。通过这种模块化架构，我们可以仅参考和下载我们需要的部分。
想象一下，如果实体框架只是一个程序集！这将是一个巨大的程序集，其中包含大量我们不需要的代码。此外，每次支持团队添加新功能或修复错误时，都必须编译和部署整个整体程序集。这将使该组件变得非常脆弱。如果我们在 SQL Server 之上使用实体框架，为什么由于 SQLite 错误修复而进行的升级会影响我们的应用程序？不应该！这就是它以模块化方式设计的原因。
在大多数 Web 应用程序中，我们一起对所有这些程序集（Web、BLL 和 DAL）进行版本控制和部署。因此，将一个项目分成 3 个项目不会增加任何价值。
来源： https:// /programmingwithmosh.com/csharp/should-you-split-your-asp-net-mvc-project-into-multiple-projects/
Some tips about split your project into multiple projects:
One reason for separating a project into multiple class libraries is re-usability. I’ve yet to see the BLL or DAL part of application re-used in another application. This is what textbooks from the 90s used to tell us! But most if not all modern applications are too specific and even in the same enterprise, I’ve never seen the same BLL or DAL parts re-used across multiple applications. Most of the time what you have in those class libraries is purely to serve what the user sees in that particular application, and it’s not something that can be easily re-used (if at all).
Another reason for separating a project into multiple class libraries is about deployability. If you want to independently version and deploy these pieces, it does make sense to go down this path. But this is often a use case for frameworks, not enterprise applications. Entity Framework is a good example. It’s composed of multiple assemblies each focusing on different areas of functionality. We have one core assembly which includes the main artifacts, we have another assembly for talking to a SQL Server database, another one for SQLite and so on. With this modular architecture, we can reference and download only the parts that we need.
Imagine if Entity Framework was only one assembly! It would be one gigantic assembly with lots of code that we won’t need. Also, every time the support team added a new feature or fixed a bug, the entire monolithic assembly would have to be compiled and deployed. This would make this assembly very fragile. If we’re using Entity Framework on top of SQL Server, why should an upgrade because of a bug fix for SQLite impact our application? It shouldn’t! That’s why it’s designed in a modular way.
In most web applications out there, we version and deploy all these assemblies (Web, BLL and DAL) together. So, separating a project into 3 projects do not add any values.
Source: https://programmingwithmosh.com/csharp/should-you-split-your-asp-net-mvc-project-into-multiple-projects/
所有权是一件事。如果您有开发人员负责代码库的不同部分，那么拆分项目是很自然的事情。人们还可以按功能划分项目。这减少了冲突和复杂性。如果它增加，那就意味着缺乏沟通，你只是做错了。
Ownership for one thing. If you have developers responsible for different parts of the code base then splitting the project up is the natural thing to do. One would also split projects by functionality. This reduces conflicts and complexity. If it increases, that just means a lack of communication and you are just doing it wrong.
不要质疑多个程序集中代码的价值，而要质疑将所有代码集中在一处的价值。
你会把厨房里的所有东西都放在一个柜子里吗？
循环引用就是循环引用，无论它们发生在程序集之间还是程序集内部。有问题的组件的设计很可能不是最优的；讽刺的是，通过程序集避开组织会阻止编译器为您检测情况。
我不明白这样的说法：您可以像使用项目一样组织代码。如果这是真的，我们的操作系统就不会有独立驱动器的概念；他们只会有一个巨大的文件夹结构。高阶组织模式表达了与简单文件夹不同的意图。
项目称“这些概念密切相关，并且仅与其他概念有外围关系。”
Instead of questioning the value of code in multiple assemblies, question the value of clumping all of your code in one place.
Would you put everything in your kitchen in a single cabinet?
Circular references are circular references, whether they happen between assemblies or within them. The design of the offending components is most likely sub-optimal; eschewing organization via assemblies ironically prevents the compiler from detecting the situation for you.
I don't understand the statement that you can organize code just as well with folders as with projects. If that were true, our operating systems wouldn't have the concept of separate drives; they would just have one giant folder structure. Higher-order organizational patterns express a different kind of intent than simple folders.
Projects say "These concepts are closely related, and only peripherally related to other concepts."
这里有一些很好的答案，所以我尽量不重复。
将代码拆分到其自己的项目的好处之一是可以跨多个应用程序重用该程序集。
我也喜欢提到的功能性方法（例如库存、运输等都可以得到自己的项目）。另一个想法是考虑部署模型。在层、层或服务器之间共享的代码可能应该位于其自己的公共项目中（如果需要更精细的控制，则应位于项目组中）。指定给某个层的代码可能位于它自己的项目中。例如，如果您有单独的 Web 服务器和应用程序服务器，那么您不会希望在应用程序服务器上部署 UI 代码。
拆分的另一个原因可能是在应用程序投入生产后允许进行小型增量部署。假设您遇到了需要修复的紧急生产错误。如果小的更改需要重建整个（一个项目）应用程序，您可能很难向 QA 证明一个小的测试周期的合理性。如果您只部署一个具有较小功能集的程序集，那么您可能会更容易销售。
There are some good answers here so I'll try not to repeat.
One benefit of splitting code out to it's own project is to reuse the assembly across multiple applications.
I liked the functional approach mentioned as well (e.g. Inventory, Shipping, etc. could all get their own projects). Another idea is to consider the deployment model. Code shared between layers, tiers, or servers should probably be in it's own common project (or set of projects if finer control is desired). Code earmarked for a certain tier may be in it's own project. e.g. if you had a separate web server and application server then you wouldn't want to deploy the UI code on the application server.
Another reason to split may be to allow small incremental deploys once the application is in production. Let's say you get an emergency production bug that needs to be fixed. If the small change requires a rebuild of the entire (one project) application you might have a hard time justifying a small test cycle to QA. You might have an easier sell if you were deploying only one assembly with a smaller set of functionality.
一些原因是
封装——通过将一组例程打包到另一个库中，无论是作为静态库还是一组 dll，它都变成了一个黑盒子。要使其成为一个好的黑匣子，您所需要做的就是确保提供正确的输入并获得正确的输出。当您重新使用该库时它会有所帮助。它还强制执行某些规则并防止黑客编程（“嗯......我现在只是将该成员函数公开”）
减少编译时间 - 库已经编译；您不必在编译时重建它，只需链接到它（假设您正在使用 C++）。
解耦 - 通过将类封装到独立的库中，您可以减少耦合并允许您将库重用于其他目的。同样，只要库的接口不改变，你就可以对库进行任何你喜欢的更改，而链接到它或引用它的其他人根本不需要更改他们的代码。 DLL 在这方面非常有用，因为无需重新编译，但如果许多应用程序安装相同 DLL 的不同版本，则使用起来可能会很棘手。您可以更新库而不影响客户端的代码。虽然您可以仅对文件夹执行相同的操作，但没有明确的机制来强制执行此行为。
此外，通过实践拥有不同库的原则，您还可以确保您编写的内容是通用的并且与实现分离。
许可/商业化——嗯，我认为这是非常明显的。
Some reasons are
Encapsulation - By packaging a set of routines into another library, either as a static library or a set of dlls, it becomes a black box. For it to be a good black box, all you need to do is to make sure you give the right inputs and get the right outputs. It helps when you re-use that library. It also enforces certain rules and prevent programming by hacks ('hmm...I'll just make that member function public for now')
Reduces compile time - the library is already complied; you don't have to rebuild it at compile time, just link to it (assuming you are doing C++).
Decoupling - By encasing your classes into a standalone libraries, you can reduce coupling and allows you to reuse the library for other purpose. Likewise, as long as the interface of the library does not change, you can make changes to the library all you like, and others who link to it or refer to it does not need to change their code at all. DLLs are useful in this aspect that no re-compilation is required, but can be tricky to work with if many applications install different versions of the same DLLs. You can update libraries without impacting the client's code. While you can do the same with just folders, there is no explicit mechanism to force this behaviour.
Also, by practicing this discipline of having different libraries, you can also make sure what you have written is generic and decoupled from implementation.
Licensing/Commercialization - Well, I think this is quite obvious.
一种可能性是拥有一个特定组（或单个开发人员）可以独立于其余代码而工作的系统。另一个方法是提取系统其余部分所需的通用实用程序代码——例如错误处理、日志记录和通用实用程序。
当然，当考虑特定函数/类/文件中的内容时，边界在哪里是艺术问题，而不是科学问题。
One possibility is to have a system that a given group (or single developer) can work on independently of the rest of the code. Another is to factor out common utility code that the rest of the system needs -- things like error handling, logging, and common utilities come to mind.
Of course, just when thinking about what goes in a particular function / class / file, where the boundaries are is a matter of art, not science.
我能想到的一个例子是，您可能会发现在开发一个项目时，您最终开发了一个库，该库可能具有更通用的用途，并且值得成为自己的项目。例如，也许您正在开发一款视频游戏，并且最终编写了一个与游戏项目无关的音频库。
One example I can think of is that you might find in developing one project that you end up developing a library which may be of more general use and which deserves to be its own project. For instance maybe you're working on a video game, and you end up writing an audio library that's in no way tied specifically to the game project.