spring.net有什么用?

时间:2010-03-05 12:56:19

标签: c# wcf silverlight spring.net

我们正在使用Silverlight和WCF服务开发应用程序。使用Spring.Net对我们有益吗?

5 个答案:

答案 0 :(得分:7)

>> “使用Spring.Net对我们有益吗?”

我认为您的问题的精神更倾向于质疑使用IoC / DI框架的好处,而不是根据需要手动管理依赖关系。我的回答将更多地关注IoC / DI的原因和原因,而不是关注使用哪个特定框架。

正如Martin Fowler在最近的一次会议上提到的,DI允许您将配置与使用分开。对我来说,根据配置和使用情况考虑DI是一个单独的问题,这是开始提出正确问题的好方法。您的应用程序是否需要为依赖项配置多个配置?您的应用是否需要能够通过配置修改行为?请记住,这意味着依赖项在运行时得到解决,并且通常需要XML配置文件,因为可以在不需要重新编译程序集的情况下进行更改。就个人而言,我不喜欢基于XML的依赖配置,因为它们最终被用作“魔术字符串”。因此,如果你最终错误拼写一个类名等,就会有引入运行时错误的危险。但如果你需要能够即时配置,这可能是今天最好的解决方案。

另一方面,有像Ninject和StructureMap这样的DI框架允许流畅的代码内依赖关系定义。您失去了即时更改定义的能力,但您可以获得编译时验证的额外好处,我更喜欢这样做。如果您想从DI框架中获得所有内容,那么您可以从等式中消除基于XML的框架。

从Silverlight的角度来看,DI可以以各种方式使用。最明显的是定义Views与ViewModels的关系。然而,更深入地,您可以定义验证,RIA上下文依赖性等。在配置类中定义所有依赖项可以使代码无需知道如何获取/创建实例,而是专注于使用。不要忘记容器可以根据您的配置管理每个对象实例的生命周期。因此,如果您需要共享类型的实例(例如Singleton,ManagedThread等),则通过声明向容器注册的每种类型的生命周期范围来支持此功能。

我刚才意识到我在咆哮,我道歉。希望这有帮助!

答案 1 :(得分:4)

就我个人而言,我建议使用Castle或Unity,因为我已经取得了巨大的成功,并且发现了两者,而不同的,优秀的IOC框架。

除了IOC组件之外,它们还提供了其他漂亮的工具(例如,城堡中的AOP,Unity中的接口拦截),您将来无疑会找到它的用途,并且从一开始就拥有一个IOC框架。总是比试图改造它容易得多。

设置和配置非常简单,虽然我个人并不是XML配置方式的忠实粉丝,因为其中一些配置文件可能会变成一场彻头彻尾的噩梦。很多人会告诉你,如果你打算交换进出组件,那么它是值得做的,但为什么不这样做呢?你决定以后需要这样做。拥有它而不是使用它更好,而不是拥有它并且需要它。如果你担心我在网上的很多博客文章中都看到了人们对各种IOC框架的速度进行比较,除非你正在创建脑外科手术机器人或美国导弹防御平台,否则它不会成为一个问题。

答案 2 :(得分:3)

使用诸如Spring.Net之类的IOC容器是有益的,因为它将使您能够通过交换应用程序接口的模拟或特殊测试实现来对UI的各个部分进行单元测试。从长远来看,这应该使您的应用程序对于未来的开发人员更易于维护。

答案 3 :(得分:2)

如果您想要更改应用程序的大块而不必重写构造函数,那么DI框架可能会有用。例如,您可能希望使用将通过接口公开的彗星流服务,然后决定您更倾向于使用专用的消息系统,如MQ或RendezVous。然后,您将向Mq编写一个尊重公共外观的适配器,只需将spring配置更改为使用Mq实现而不是Comet实现。

但是为了爱上 tony the pony ,不要使用Spring.Net为每个视图创建MVVM / MVP / MVC绑定,否则你将进入一个痛苦的世界。

与parcimony一起使用时,DI是一个很棒的工具,请不要使用243个弹簧配置文件,以保证开发人员的理智。

答案 4 :(得分:0)

我认为如果您在代码中执行更多操作而不是使用标记来执行绑定等,并且有BAL / DAL DI可以帮助那里,因为它可以注入正确的业务组件引用(作为一个示例)。 DI还有许多其他实际优点,但是你必须在代码中做更多,而在标记方面做得更少。

相关问题