• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 3, 文章 - 0, 評論 - 16, 引用 - 0
            數據加載中……

            關于PocoCapsule中reflection及動態proxy的討論

            原文是貼在我E文博客中,先轉過來有空再譯:

            In the pococapsule newsgroup, someone asked the following question about dynamic invocation proxies in PocoCapsule:

            As far as i understand, these proxies are dependent on the configuration file (e.g. setup.xml).... I would think that the need for recompiling the proxy when the configuration file changes is a "big disadvantage". One of the great things of IoC is that the system can be configured by "just" changing the configuration file. But now users also have to recompile reflextion proxies (?). ... Can pxgenproxy generate reflextion code for ALL classes in the specified .h file(s)?

            I would like to use this opportunity to clarify several related issues:

            First of all, with PocoCapsule, one does not need to recompile dynamic proxies under configuration changes that only modified function invocation parameter values. One only needs to rebuild new proxies for new function invocation signatures involved in the new configuration. In my opinion, this is not only desirable (no recompilation on parameter value changes) but also acceptable (build new dynamic proxies for new signatures). The assumption is that real world application configurations should avoid applying new invocation signatures that have never been tested before. This kind of usage scenario automatically avoids the need of an on-the-field recompilation after a reconfiguration. Because all dynamic proxies to be used by the application on field should have been generated and compiled for deploying the application during QA tests.

            Secondly, many popular IoC containers today even favor static solutions over dynamic configurations. In these manual programmatic based (such as the PicoContainer without the Nano) or metadata based (such as the Spring Framework with Spring-Annotation) solutions, not only new function signatures but even parameter value changes in configurations would force recompilations. Although I am not keen on these solutions (especially the recompilation under value change is highly undesirable in my opinion), I do believe that these well accepted and even enthusiastically pursued solutions indicate that such a recompilation does not bother real world applications.

            This is not because the industry does not recoganize the claimed "disadvantage" of the on-the-field recompilation implied in these hot solutions, but because IoC frameworks are not intended to be yet another scripting environment. Rather, IoC frameworks are mainly for:

            • Separating plumbing logic (component life cycle controls wirings, initial property settings etc.) from business logic and supporting framework agnostic business logic components.
            • Allowing user to setup (configure/deployment/etc.) an application declaratively (by expressing what it is alike, rather than the procedure of how to build it step-by-step),
            • Supporting the idea of software product lines (SPL) based on reusable and quickly reconfigurable components and domain-specific modeling.
            Whether a given IoC framework is able to avoid on-the-field recompilation when new signatures appearing in the declarative configuration descriptions is merely a bells-and-whistles feature rather than a "great thing" (neither a "big disadvantage" if it does not support it). In PocoCapsule, generated dynamic proxies are very small and cost neligable recompilation time for most applications, not to mention that:
            • On-the-field recompilation can largely be avoided if component deployments have been pre-tested (as discussed in the beginning).
            • This recompilation need even less time than packaging deployment descriptors (such as package them into .war/.ear/.zip files).
            Now, let's take a look on those seemingly "minor" disadvantages from the suggested solution that generates proxies for all classes in specified header files:
            • More manually code fixes: I would suggest one to play some of relevant utilities, such as GCC XML, on various header files on different platforms (including Windows, various unix/linux, VxWorks, Symbain OS, etc. Because IoC frameworks do not (and should not) prohibit user to use non-portable components, the utilities that parsing header files would have to either deal with non-portable header files (including various platform specific C++ extensions) or require users to fix those header files manually before parsing. In the suggested scenario, the developers who were only going to configure the application at high level would have to apply more low level code fix effort.
            • Bloated code generation and heavy runtime footprint: Based on various application examples, we compared PocoCapsule generated proxies code to CERN REFLEX that generate all proxies of classes in specified header files. Typically, one would see REFLEX produces 10 to 1,000 times more code than it was actually needed for an IoC configuration. These redundent code eat megas of runtime memory (instead of few or few tens kilos). This is because in the suggested solution, one would have to generate proxies for all classes that were implicitly included (declared in the other header files that were include by specified header files), proxies for all classes that were used as parent classes of some other classes, and proxies that are used as parameters of class methods, etc.. Otherwise, it would be merely 50 yards vs 100 yards, namely, one would still have the claimed "big" disadvantage of having to rebuild proxies after all.
            • Human involved manually edited filters: Utilities, such as GCC XML (and therefore the CERN REFLEX), allows one to filter out unwanted proxies to reduce the size of generated code. However, one would have to manually edit filter configurations. The consequence of applying such filters are more code (or script) and more complexities to be handled and mantained manually. This immediately defeats the whole point of using the IoC frameworks.
            • Additional footprint for a runtime type system: To support OO polymorphism (e.g. components that extend from interfaces) without recompilation, simply generating all proxies is not sufficient. The solution would have to provide a runtime type system (and additional metadata as well). This will increase the application runtime footprint roughly by another ~1Mbytes.
            • Generic programming (GP) would be prohibited: As we know, C++ template specialization mandates recompilation. We can't have compiled code that could be applied to all possible specializations. To ensure no recompilation, the solution would have to accept a "minor" disadvantage, namely prohibit the use of GP. GP is used heavily in many PocoCapsule examples (see those corba examples that use "native" servant implemention). It significantly shortens the learning curve of some middlewares, such as CORBA (one no longer need to learn POA skeletons), simplifies application code, and supports legacy components with much less refactoring cost.
            With all these disadvantages what one would gain was a merely an "advantage" that could help him to shoot himself in the foot -- to deploy an application that involves wirings that have never been tested previously.

            posted on 2008-03-10 03:11 kjin101 閱讀(1123) 評論(0)  編輯 收藏 引用

            久久亚洲精品国产亚洲老地址| 久久精品亚洲精品国产色婷| 国产99久久久国产精品~~牛| 狠狠精品干练久久久无码中文字幕| 久久久久亚洲av毛片大| 精品久久久久久无码不卡| …久久精品99久久香蕉国产| 久久成人国产精品一区二区| 亚洲AV无码一区东京热久久| 久久精品?ⅴ无码中文字幕| 蜜臀av性久久久久蜜臀aⅴ| 久久露脸国产精品| 久久精品国产精品国产精品污 | 国内精品免费久久影院| 久久精品综合网| 99久久国产亚洲高清观看2024 | 久久精品午夜一区二区福利| 久久噜噜久久久精品66| www.久久99| 日韩精品久久久久久免费| 久久综合久久性久99毛片| 色偷偷888欧美精品久久久| 午夜不卡久久精品无码免费| 亚洲欧美日韩久久精品| 久久久久久毛片免费看| 久久精品免费一区二区三区| 久久综合给合久久国产免费| 亚洲色婷婷综合久久| 人人狠狠综合久久亚洲高清| 久久久综合香蕉尹人综合网| 久久久久亚洲精品男人的天堂| 久久香蕉国产线看观看99| 91久久精一区二区三区大全| 奇米综合四色77777久久| 亚洲精品乱码久久久久久蜜桃图片| 性欧美大战久久久久久久| 久久天天躁狠狠躁夜夜2020老熟妇| 久久久久亚洲?V成人无码| 久久国产精品免费一区二区三区| 久久综合久久久| 久久www免费人成看国产片 |