110,536
社区成员
发帖
与我相关
我的任务
分享请问动态加载dll和直接引用dll有什么区别 ？
有一WinForm程序A，和包含另一个Form的dll库B，A和B中的数据都是各自独立，A、B代码都是已知的，A一定会用到B，B一定会随着A一起发布，名称也是固定的。
以前我的习惯是A工程中直接引用B的dll，然后创建B中Form的实例即可使用，可是看到一个做法是在A中Assembly.LoadFrom(B.dll)，然后assembly.CreateInstance(“B的Form名”)这样来调用B中的Form。
不知这样动态加载和直接在工程中引用，有什么区别呢？
以前我的习惯是A工程中直接引用B的dll，然后创建B中Form的实例即可使用，可是看到一个做法是在A中Assembly.LoadFrom(B.dll)，然后assembly.CreateInstance(“B的Form名”)这样来调用B中的Form。
不知这样动态加载和直接在工程中引用，有什么区别呢？
...全文
请发表友善的回复…
发表回复
xjacks 2014-07-10
- 打赏
- 举报
有道理，学习了！
xjacks 2014-07-10
- 打赏
- 举报
谢谢回复。如果在我提到的情况下“A一定会用到B，B一定会随着A一起发布，名称也是固定的”，那么动态加载应该是没有什么意义的吧？
於黾 2014-07-10
- 打赏
- 举报
反射效率确实挺高的,但是毕竟和直接知道名字不同,还要去搜索,不管微软做的搜索算法多么高效,毕竟还是有效率下降
当然如果你的程序对于时间不是特别敏感,是可以无视的
还有一种情况,类似于5楼所说的
我框架异常复杂,DLL加起来有好几百个,但是不同用户需要用到的功能其实不一样
那么我没必要为不需要那个功能的用户静态加载好几百用不着的DLL,甚至DLL都不应该存在于客户机中
我应该在判断用户需要用到这些DLL,就从服务器上DOWN下来,然后动态加载到内存中.
thy442030800 2014-07-10
- 打赏
- 举报
都是使用，没区别
主要体现在设计上，动态加载灵活一些，我们现在的项目就是
所有的功能都做成一个个的DLL文件，DLL的文件名和方法名都存放在数据库中，框架使用反射，动态加载，来调用功能
当然，据本人没证实过的说法，动态加载可能效率低那么一点点
又有说法说当今反射的效率是很高的，可以无视
所以，管它呢
以专业开发人员为伍 2014-07-10
- 打赏
- 举报
要知道的是，”世事比人强“的道理。因此你在学校学的那点东西，拿到实际工程中还是需要从头学起的，你需要知道的因为工程原因而变得更加动态的东西越来越多。
但是我们绝对不能因为一个东西时髦，”看起来挺厉害似地“而去使用它。脱离了稳定性、易测试性等要求而追求抄袭来的时髦代码的人，自己可能没有处理过多少bug问题。如果一个设计可以很好地静态处理，决不可胡乱追求动态特性。
以专业开发人员为伍 2014-07-10
- 打赏
- 举报
没有必要动态加载DLL的时候，我们当然去动态调用它 --> 没有必要动态加载DLL的时候，我们当然尽量不去动态调用它
以专业开发人员为伍 2014-07-10
- 打赏
- 举报
如果说区别，就是有些时候应用程序根本不可能预先知道需要访问的DLL，所以无法引用。
例如你写一个”快递单处理流程“软件，但是你不知道到底有几百种快递单，你可以在你的程序中写一个通用的快递单的接口（从中可以读取布局的模式信息，例如读取BitImage类型的底图，读取各个业务数据的文本框的坐标位置，等），并且写两种具体的快递单作为测试。
可是实际使用时，另外有198种快递单，怎么办？这就需要用一个配置文件，将其它快递单”应该从哪一个名称的DLL中的什么类型（显然全都实现了你的接口）取得“信息一一列出来，这样才能让你的程序真正发挥价值。
这种扩展设计，可能就需要动态加载DLL。
因此这取决你是懂设计的人，还是不懂设计的人。
没有必要动态加载DLL的时候，我们当然去动态调用它，而应该直接在工程中引用它。只有在必要的时候才动态加载DLL。
wangnaisheng 2014-07-10
- 打赏
- 举报
