• <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 閱讀(1124) 評論(0)  編輯 收藏 引用

            久久久久国产一区二区| 99国产欧美久久久精品蜜芽| 亚洲人成无码www久久久| 久久亚洲精品国产精品婷婷| 色8久久人人97超碰香蕉987| 久久精品男人影院| 无码人妻少妇久久中文字幕蜜桃 | 色综合合久久天天给综看| 新狼窝色AV性久久久久久| 情人伊人久久综合亚洲| 亚洲午夜久久久影院伊人| 性做久久久久久久久老女人| 国产一级持黄大片99久久| 日日噜噜夜夜狠狠久久丁香五月 | 久久精品国产精品亜洲毛片| 久久亚洲中文字幕精品有坂深雪| 久久亚洲精品无码观看不卡| 嫩草影院久久99| 成人资源影音先锋久久资源网| 久久久久精品国产亚洲AV无码 | 久久亚洲春色中文字幕久久久| 无码精品久久一区二区三区 | avtt天堂网久久精品| 少妇久久久久久久久久| 国产精品久久久久免费a∨| 久久久WWW成人免费毛片| 久久精品中文字幕有码| 久久久精品久久久久特色影视| 国产精品99久久不卡| 国产精品嫩草影院久久| 精品久久久久久国产三级| 国产A级毛片久久久精品毛片| 久久综合九色综合97_久久久| 久久不射电影网| 久久免费精品一区二区| 狠狠人妻久久久久久综合蜜桃| 国产高清国内精品福利99久久| 国产精品九九久久精品女同亚洲欧美日韩综合区 | 久久精品亚洲精品国产欧美| 久久婷婷五月综合色99啪ak| 久久久午夜精品福利内容|