Question

我有一些与框架依赖有关的问题。一般说来,最好的编码做法是,不把你的名字放在框架特定代码上。例如,就春天而言,所有依赖性都应保留在编织档案中,而且你的申请法典中没有任何春季的特写法(这是在春天通知中选择春confXml文档的原因之一)。如果是纯净重物,则总是最好不要将纯净重物法混为一谈,因此,你的意见可以与任何框架合作。但我的问题是:

If we remove spring or puremvc from your code without replacing any other framework then you are end up in few beans (in case of spring) or some truly reusable views (in case of puremvc). But gluing beans or view requires large amount of coding effort, according to me its indirect dependency of framework without using framework specific api.
If we replace spring with other DI framework like pico container then also it requires substantial amount or rework. Which again leads to indirect dependency on framework.

因此,它为什么不把我们的申请名称放在具体框架中? 就我们而言,我们可以制定具体框架(如果它真正能够大大缓解我们的编码努力)。

据我说,不把申请名称空间与具体框架混为一谈,就使你的申请可以用于其他框架。如果你想把你现有的设计良好的休战申请移到春天,以及它需要多少努力。

其他读者的观察。

Answer 1

与软件开发的所有抽象概念一样,你只是把问题放在你使用框架时。该框架关注某些事项,因此,你申请的其他部分无需知道如何这样做。例如,如果你使用依赖注射方式注射,那么就不必知道如何创造其依赖性,则由依赖注射框架处理。

但这只是意味着知识/责任得到转移。永远不会放弃<>re>/strong>。因此,当然,你的守则隐含地取决于这一框架。但是,如果你将框架相关守则移至一个地点,甚至可能引入一些接口以加以总结,那么你有时可以做到,这样,你的法典的其余部分就取决于a<><>>>>接口、类别或框架,而不是具体框架。

例如,我在守则中采用了IIocContainer接口,但只有Resolve方法。执行这一接口的一个目标掌握了how的知识,以称之为具体的国际住户/移民框架。但这一知识只是在这个目标中。我的其余申请(视需要)只知道IIocContainer接口,因此并不取决于具体框架。如果我改变框架,我只需要改变参考资料和配置(可能出现在XML中,而根本不会影响代码),并使用一个为这一集装箱安装IIocContainer的不同物体。

当你再次谈到直接影响到你的法典结构/结构(例如,按基级、命名公约等)的框架时,就意味着要从具体框架中删除变得更困难。阁下:could,但你基本要做的是围绕另一个框架撰写自己的框架。这样做是值得 w的,因为归根结底,如果你重新转向结构框架,那么它就会成为许多工作,要么直接为这一框架进行重写,要么把框架推到一边。

我认为,你可以把它简单地说成:如果你重新利用一个框架,把许多结构性pl倒的问题移到这个框架中(删除框架,为你铺设管道),那么你将重新启动许多结构性umb,以便解决问题。

Answer 2

我认为,它是软件设计的一个基本主干,以保持你的关切分离。就像你不想在多国公司示范层看到代码一样,你在应用守则中不希望使用集装箱特定代码。

你正确地认为,在许多情况下,需要为其工具撰写编码。例如,如果需要某种习俗类型,或如果需要某种习俗应用环境的话,你可以撰写一些保密的具体法典。没有什么错误。关键是要将其与你申请的其他功能分离。

这不能保证“随时”的便携性。它所促进的是能够在其他地方“容易”携带该守则。在这方面,“容易”并不意味着没有工作。相反,这意味着,由于你决定去Pico,你不得不开始跳出春天的具体 st子。换言之,你的核心业务功能仍然无所作为,在你决定迁移时,你们必须做的是把组合或集装箱特定依赖物港。

友情链接