在我的项目中,我们已经设置了一些现有的dll,我想按原样使用它们。但这会在多个dll之间创建级联调用。以下是呼叫流程:
我的申请面临哪些问题?请告诉我这个提议的优点和缺点。
注意:将新开发First.dll和Second.dll .Third.dll是现有的dll,将被重用。即使将来,我们也可能遇到可以新开发Third.dll的情况。我想知道应用程序可以面对多个dll之间的级联调用有什么问题吗?
答案 0 :(得分:0)
“如果它有效,请不要修复它”意味着如果它们“按原样”工作那么它就没问题了。我收集这些DLL是现有的吗?这样设计和测试一起工作?如果是这样,他们也会为你工作。欢呼声。
但是,如果您计划自己构建这些或者有一组备用DLL,那么我建议使用更简单的架构而不使用级联DLL。当DLL或DLL级别较少时,调试和开发更容易。但是,如果您手边有经过测试的设置,请不要打扰自己。
答案 1 :(得分:0)
只有在您希望将共享功能分离出来以便在不同项目中使用它们时,才应在此上下文中使用DLL。如果您只需要一个程序来访问该功能,则没有理由将其分离到库中。
在级联呼叫的情况下,您将面临比您自己的应用程序中的呼叫更重的开销。这是因为装配发生了变化。
以下是类成员正常调用的粗略表示:
push 0 ; a parameter
push 1 ; another parameter
push eax ; pointer to the class instance
call Program.SomeMethod ; direct call to the method
这非常快。当您包含DLL时,您必须通过IAT执行调用。这增加了执行时间。同样,这是一个严格的简化:
push 0
push 1
push eax
call <Program.IAT_1>
...
Program.IAT_1:
jmp DLL1.SomeCall
...
DLL1.SomeCall:
; more code here
call <DLL1.IAT_1>
...
DLL1.IAT_1:
jmp DLL2.SomeOtherCall
...
DLL2.SomeOtherCall
; actual code here
ret
由于您正在跨模块调用,如果您经常调用此函数,则会产生很大的开销。
还有许多与维护和部署相关的问题,这使得在不需要的时候不分拆出来更为谨慎。
在这种情况下,您应该将其拆分的唯一原因是您计划在另一个应用程序中使用某些代码。即使在这种情况下,您也不需要多个DLL。