将 WPF 应用程序拆分为多个 dll 是好是坏

本文关键字:dll WPF 应用程序 拆分 | 更新日期: 2023-09-27 18:33:46

以前,我的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 中来再添加两个 dll。视图模型.dll。

现在我的问题是,这是将单个 EXE 吐到多个 dll 中的好方法吗?

请让我知道这样做的优缺点。

我有一些意见,比如,如果有更多的dll,JIMS将很难.exe使用该应用程序联系许多dll。因为对于每个调用,它都必须读取相应的 dll。

提前谢谢。

将 WPF 应用程序拆分为多个 dll 是好是坏

我还没有看到它被提及,所以我会加入。

根据我的经验,在 C# 中使用此方法的主要原因是exchangeability - 能够轻松替换系统的某些部分。

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

我不能告诉你它是"好"还是"坏"——这是你特定目的所需要的。我可以告诉你的是,这不是"错的"。

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

它有很多好处:

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

但它有一些负面的观点:- 您的用户可以删除dlls(如果他们真的很愚蠢(,然后想知道为什么该程序不再工作- 没有dll,您的用户可以快速构建便携式版本

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

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

对我来说,这感觉像是MVVM的一大好处,特别是如果你将组件分解成单独的项目/库。

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

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

关于动态呼叫的好处

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

关于动态呼叫的坏事

  1. 每个动态调用的子例程都必须作为 DLL 链接(除非使用导入库公开 DLL 中的其他入口点(。因此,如果应用程序由数百个子例程组成,并且它们都是动态调用的,则需要分发数百个 DLL。
  2. 可以混合使用 DLL 的版本。 这可能是分发应用程序和最终用户不正确地安装更新的问题。
  3. 如果缺少某个 DLL,则在用户执行尝试调用该 DLL 的某些工具之前,您可能不知道它。 此时,除非您处理这种情况,否则您的应用程序将异常终止。
  4. 如果您调用 DLL,取消它,
  5. 然后再次调用它,则会产生更多的 I/O,因为如果您取消例程,则需要重新加载它。 这可能会降低应用程序的速度,因为它需要更多的磁盘活动。 同样,在Windows环境中,这通常是不必要的,因为Windows在管理内存方面做得非常出色。
  6. 如果混合和匹配对同一子例程的静态和动态调用,则软件可能同时在内存中具有多个不同的版本。 猜猜尝试调试那个烂摊子会有多有趣?

有关更多信息,请参阅此处