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