将WPF应用程序拆分成多个dll是好还是坏？

时间：2012-05-11 05:49:22

标签： c# .net wpf dll exe

以前我的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。

提前致谢。

6 个答案:

答案 0 :(得分：4)

我还没有看到它提到过，所以我会参与其中。

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

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

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

答案 1 :(得分：0)

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

答案 2 :(得分：0)

它有很多好处：

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

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

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

答案 3 :(得分：0)

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

对我而言，感觉就像MVVM的巨大优势之一，特别是如果您将组件分解为单独的项目/库。

答案 4 :(得分：0)

我们目前正致力于针对特定利基市场的大规模应用，但我们的许多客户需要小型定制应用，这些应用虽然根据他们的需求量身定制，但他们经常使用产品的许多不同功能。数据库。因此，我们将Wpf应用程序拆分为许多不同的程序集，这是能够执行此操作的唯一真正方法。在许多方面，它几乎使这些额外的工具，我们创建了一个新的开发和部分集成现有的开发，使这些新的应用程序很快与大多数测试的代码放在一起。

答案 5 :(得分：-1)

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

关于动态CALL的好事

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

    6. 关于动态CALL的坏事

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

      6. 有关详细信息，请参阅Here

相关问题
最新问题