将开发项目（例如ASP.NET MVC应用程序）拆分为多个项目的常见原因是什么？代码组织也可以通过文件夹完成。多个项目往往会产生循环引用冲突，并且必须通过管理/解决这些冲突来增加复杂性。
那么，为什么？
答案 0 :(得分：5)
有些原因
封装 - 通过将一组例程打包到另一个库中，无论是作为静态库还是一组dll，它都变成了一个黑盒子。为了成为一个好的黑匣子，你需要做的就是确保你提供正确的输入并获得正确的输出。当您重新使用该库时，它会有所帮助。它还强制执行某些规则并阻止黑客编程（'嗯......我现在只是将该成员函数公开'）
减少编译时间 - 库已经被编译;您不必在编译时重建它，只需链接到它（假设您正在使用C ++）。
解耦 - 通过将类包装到独立库中，可以减少耦合并允许您将库重用于其他目的。同样，只要库的界面没有改变，您就可以随意更改库，而其他链接到它或引用它的人根本不需要更改它们的代码。 DLL在这方面很有用，不需要重新编译，但如果许多应用程序安装相同DLL的不同版本，则可能很难处理。您可以在不影响客户端代码的情况下更新库。虽然你可以只使用文件夹，但没有明确的机制来强制这种行为。
此外，通过练习具有不同库的这一学科，您还可以确保您所编写的内容是通用的并与实现分离。
许可/商业化 - 嗯，我认为这很明显。
答案 1 :(得分：3)
一种可能性是让一个给定组（或单个开发人员）可以独立于其余代码工作的系统。另一种方法是将系统其他部分所需的常用实用程序代码分解出来 - 记住错误处理，日志记录和常用实用程序等内容。
当然，在考虑特定功能/类/文件中的内容时，边界是艺术问题，而不是科学问题。
答案 2 :(得分：2)
有关将您的项目分成多个项目的一些提示：
将项目分为多个类库的一个原因是可重用性。我还没有看到应用程序的BLL或DAL部分在另一个应用程序中重复使用。这就是90年代的教科书用来告诉我们的！但是，即使不是全部，大多数现代应用程序也过于具体，即使在同一企业中，我也从未见过在多个应用程序中重复使用相同的BLL或DAL部分。在大多数情况下，这些类库中的内容纯粹是为用户在特定应用程序中看到的内容提供服务，而不是可以轻松重复使用的东西（如果有的话）。
将项目分成多个类库的另一个原因是关于可部署性。如果您想独立地版本化和部署这些片段，那么走这条路确实很有意义。但这通常是框架的用例，而不是企业应用程序。实体框架就是一个很好的例子。它由多个程序集组成，每个程序集专注于不同的功能领域。我们有一个包含主要构件的核心程序集，还有一个用于与SQL Server数据库对话的程序集，还有一个用于SQLite的程序集，依此类推。使用这种模块化体系结构，我们可以仅参考和下载所需的部分。
想象一下，如果Entity Framework仅是一个程序集！这将是一个巨大的程序集，其中包含许多我们不需要的代码。此外，每次支持团队添加新功能或修复错误时，都必须编译和部署整个整体组件。这将使该组件非常脆弱。如果我们在SQL Server上使用Entity Framework，为什么由于SQLite的错误修复而进行的升级会影响我们的应用程序？不应该！这就是为什么它采用模块化方式进行设计的原因。
在大多数Web应用程序中，我们对所有这些程序集（Web，BLL和DAL）进行版本控制和部署。因此，将一个项目分为3个项目不会增加任何值。
层是概念性的。他们没有身体上的表现 码。拥有名为BLL或DAL的文件夹或程序集并不意味着 您已经正确地对应用程序进行了分层，但这并不意味着您 具有改善的可维护性。可维护性是关于干净的代码， 小方法，小类，每个类都有一个职责，并且 这些类之间的耦合有限。用脂肪分割项目 BLL / DAL项目中的课程和胖方法并不能改善 软件的可维护性。程序集是版本控制的单位 和部署。如果您想将一个项目分成多个项目 在其他项目中重复使用其中的某些部分，或者如果您想 独立版本化并部署每个项目。
答案 3 :(得分：1)
我能想到的一个例子是，您可能会在开发一个项目时发现，您最终开发的库可能更常用，并且值得成为自己的项目。例如，你可能正在开发一款视频游戏，而你最终会编写一个与游戏项目无关的音频库。
答案 4 :(得分：1)
代码重用。假设您有项目A，并且您启动了一个新项目B，它具有许多与项目A相同的功能。将A的共享部分拉出并将它们组成一个可供A和B使用的库是有意义的。这使您可以在两个地方都拥有代码而无需在两个地方维护相同的代码。
代码重用，倒置。假设您有一个在一个平台上运行的项目。现在您希望它在两个平台上运行。如果您可以分离出与平台相关的代码，则可以为每个依赖于平台的库启动不同的项目，然后使用不同的库为不同的平台编译中央代码库。
答案 5 :(得分：1)
不要质疑多个程序集中代码的价值，而是要质疑在一个地方聚集所有代码的价值。
你会把厨房里的所有东西放在一个柜子里吗？
循环引用是循环引用，无论它们是在程序集之间还是在程序集之间。违规组件的设计很可能是次优的;通过程序集避开组织具有讽刺意味的是阻止编译器为您检测情况。
我不明白你可以像文件一样组织代码和文件的声明。如果这是真的，我们的操作系统将没有单独驱动器的概念;他们只有一个巨大的文件夹结构。高阶组织模式表达了与简单文件夹不同的意图。
项目说“这些概念密切相关，只与外围的其他概念有关。”
答案 6 :(得分：0)
拥有一件事。如果开发人员负责代码库的不同部分，那么将项目拆分是很自然的事情。人们也会按功能分割项目。这减少了冲突和复杂性。如果它增加，那只是意味着缺乏沟通而你只是做错了。
答案 7 :(得分：0)
这里有一些很好的答案，所以我会尽量不重复。
将代码拆分为自己的项目的一个好处是在多个应用程序中重用该程序集。
我也喜欢上面提到的功能方法（例如库存，运输等都可以获得自己的项目）。另一个想法是考虑部署模型。层，层或服务器之间共享的代码应该在它自己的公共项目中（如果需要更好的控制，则应该在项目集中）。专用于特定等级的代码可能属于其自己的项目。例如如果您有一个单独的Web服务器和应用程序服务器，那么您不希望在应用程序服务器上部署UI代码。
拆分的另一个原因可能是在应用程序投入生产后允许小的增量部署。假设您遇到需要修复的紧急生产错误。如果小的更改需要重建整个（一个项目）应用程序，那么您可能很难将小测试周期证明为QA。如果只部署一个具有较小功能集的程序集，则可能更容易销售。