将 WPF 应用程序拆分为多个 dll 是好是坏？ [关闭]答案

【问题标题】：Is Splitting WPF Application into multiple dll's is good or bad? [closed]将 WPF 应用程序拆分为多个 dll 是好是坏？ [关闭]
【发布时间】：2012-05-11 05:49:22
【问题描述】：

以前我的 WPF 应用程序大小为 4096KB，作为单个 .exe 文件。

现在我已经像这样将应用程序拆分为多个

JIMS.exe           Main Application-->103KB
JIMSDAL.dll        Data Access Layer-->43KB
JIMS.Core.dll      Core classes for MVVM-->110KB
JIMS.Commands.dll  MVVM Commands-->11KB
JIMS.Controls.dll  WPF UserControls-->25KB
JIMS.Resources.dll Fonts,icons and xaml resources.-->44KB
UtilityClasses.dll Other classes like Helper classes-->10KB

我正在进一步考虑通过将视图模型从 JIMS.exe 删除到 JIMS.ViewModel.dll 中来添加另外两个 dll。

现在我的问题是，这是将单个 EXE 吐入多个 dll 的好方法吗？

请告诉我这样做的优点和缺点。

我有一些意见，如果有更多的 dll，JIMS.exe 将难以使用该应用程序联系许多 dll。由于每次调用都必须读取相应的 dll。

提前致谢。

【问题讨论】：

单个.exe有什么问题？
我想，当一个大小为 4096KB 的 exe 被加载时，我会比加载一个 103KB 的 exe 消耗更多的空间，然后它只会加载它需要的 dll。
您的 exe 已经使用了很多 dll（来自 .NET 框架）。是不是很挣扎？
你动态链接更好。

标签： c# .net wpf dll exe

【解决方案1】：

我没看到有人提到过，所以我会加入。

根据我的经验，在 C# 中使用这种方法的主要原因是 exchangeability - 可以轻松替换系统的某些部分。

举个例子，我们在我当前的项目中使用这种方法。每个 GUI 组件（或UserControl）都是它自己的 dll，并在启动时动态导入。这允许我们为我们的 GUI 实现一个插件架构，并允许我们的 GUI 开发人员在单独的项目中工作，而不必加载所有逻辑/等。

我无法告诉你它是“好”还是“坏”——这是你为特定目的所需要的。我可以告诉你的是，这不是“错误”。

【讨论】：

【解决方案2】：

如果您打算在其他项目中独立使用这些 dll，那么请确保您可以拆分它们，否则有什么好处？我不确定您的应用程序，但如果您正在编写一个控件，供其他开发人员使用或将应用程序集成到其他应用程序中，那么单独管理 dll 可能会成为一项艰巨的任务。我不太确定你的最后意见。我希望看到社区对此的意见

【讨论】：

【解决方案3】：

它有很多好处：

-如果你做一个小更新，你的用户不需要下载完整的 exe，他们只需要下载一些小很多的 dll - 如果您正在编写另一个使用 dll 的程序，您的用户可以节省内存 - 如果您的程序变得庞大并且您有几分钟的构建时间，您不必全部重新构建，如果您正在进行更改，您可以再次构建更改后的 dll

但它有一些负面的观点： -您的用户可以删除 dll（如果他们真的很愚蠢），然后想知道为什么程序不再工作了 - 无需 dll，您的用户可以快速构建便携版本

如果你的项目很大（听起来像，因为 4MB exe），我会拆分程序，但如果它是一个小程序，我不会拆分程序。

【讨论】：

【解决方案4】：

我在我正在开发的应用程序中采用了类似的方法，但对我来说，主要原因是支持开发应用程序的控制台版本。这样我就可以使用 XAML GUI 在应用程序中提供简单的一次性操作，然后使用控制台版本安排更长时间的运行/维护操作。它们都使用相同的模型和视图模型层，但显然是不同的“视图”。

对我来说，这感觉像是 MVVM 的一大好处，尤其是当您将组件分解为单独的项目/库时。

【讨论】：

【解决方案5】：

我们目前正在开发针对特定利基市场的大规模应用程序，但我们的许多客户需要小型定制应用程序，这些应用程序虽然根据他们的需求量身定制，但他们经常使用产品的许多不同功能，而这些应用程序使用单一数据库。因此，我们将 Wpf 应用程序拆分为许多不同的程序集，这是能够做到这一点的唯一真正方法。在许多方面，它几乎使我们创建的这些附加工具一部分是新开发，一部分是集成现有开发，这使得这些新应用程序可以非常快速地与大部分经过测试的代码组合在一起。

【讨论】：

所以...答案是说“它不仅仅是好，有时/经常是必须的”？

【解决方案6】：

最好将应用程序拆分为多个 dll。这使得项目更易于管理，更容易添加/删除功能，更容易使用现有的 dll 编写全新的应用程序。我认为动态链接更适合应用程序.....

动态调用的好处

如果您更改子例程中的某些内容，则无需重新链接您的应用程序；只有子例程 DLL 需要重新链接。
调用此子例程的所有可执行文件将共享同一个 DLL；代码和数据。由于您的应用程序只加载一个动态调用的子例程的副本，因此它使用的内存更少。
动态调用的子例程中包含的值更改可供所有使用它的 DLL 使用，因为它们都共享子例程的同一副本。
您可以通过取消子例程来释放动态调用的子例程正在使用的内存。然而，这在 32 位 Windows 虚拟内存环境中通常没有多大用处，因为无论如何 Windows 都会从计算机的实际内存池中“分页”非活动数据。
列表项

动态调用的坏处

每个动态调用的子例程都必须作为 DLL 链接（除非您使用导入库来公开 DLL 中的其他入口点）。因此，如果您的应用程序包含数百个子例程并且它们都是动态调用的，那么您将需要分发数百个 DLL。
可以混合使用不同版本的 DLL。这对于分发您的应用程序和最终用户安装更新不正确都可能是个问题。
如果您的某个 DLL 丢失，您可能直到用户使用一些尝试调用该 DLL 的工具时才知道它。届时，除非您处理这种情况，否则您的应用程序将异常终止。
如果你调用一个 DLL，取消它，然后再次调用它，你会产生更多的 I/O，因为如果你取消它，例程需要重新加载。这会降低应用程序的速度，因为它需要更多的磁盘活动。同样，在 Windows 环境中，这通常是不必要的，因为 Windows 在管理内存方面做得非常出色。
如果您将静态和动态调用混合并匹配到同一个子例程，您的软件可能会同时在内存中拥有多个不同的版本。猜猜尝试调试这个烂摊子会有多有趣？

欲了解更多信息，请参阅Here

【讨论】：

是否还有带有 .NET 程序集的链接器？
几乎每个项目符号都不适用。