spring.net有什么用？

Question

我们正在开发一个使用Silverlight和WCF服务的应用程序。是否使用Spring.Net对我们有利？

Answer 1

如果您想要更改应用程序的大块而不必重写构造函数，则DI框架可能会有用。例如，您可能希望使用您将通过界面公开的慧星流式服务，然后再决定使用MQ或RendezVous等专用通信系统。然后你将编写一个适配器给Mq，这个适配器尊重普通的外观，只需要改变spring配置来使用Mq实现而不是Comet。

但是对于tony的小马的爱，不要使用Spring.Net为每个视图创建MVVM/MVP/MVC绑定，否则您将进入一个痛苦的世界。

与parcimony一起使用时，DI是一个很好的工具，请不要因为您的开发人员的理智而终止于243个弹簧配置文件。

Answer 2

我认为如果您在代码中做的更多，而不是使用标记来进行绑定等，并且BAL/DAL DI可以帮助解决问题，因为它可以注入正确的业务组件引用（作为一个示例）。 DI还有许多其他的实际优点，但是你必须在代码中做更多的事情，而不是在标记中做更多事情。

Answer 3

使用IOC容器（如Spring.Net）是有益的，因为它使您能够通过交换应用程序接口的模拟或特殊测试实现来单元测试部分UI。从长远来看，这应该会让您的应用程序更易于维护以便未来的开发人员使用。

Answer 4

就我个人而言，我推荐使用Castle或Unity，因为我已经与他们取得了巨大的成功，并且发现他们都是不同的，出色的IOC框架。

除了IOC组件之外，它们还提供其他漂亮的工具（例如Castle中的AOP，Unity中的Interface interception），您将来无疑会找到它的用处，并且从一开始就有一个IOC框架总是比试图改装它容易得多。

它的设置和配置非常简单，尽管个人而言我并不是XML配置方式的狂热爱好者，因为其中一些配置文件可能变成完全的恶梦。很多人会告诉你，如果你打算交换组件，唯一值得的做法是，但为什么不这样做呢？无论如何，你决定你以后需要这样做。拥有它并且不使用它比拥有它并且需要它更好。如果您担心我在网络上的许多博客文章中看到的perf perf命中，人们会比较各种IOC框架的速度，除非您正在创建脑外科手术机器人或美国导弹防御平台，否则不会是问题。

Answer 5

> >“正在使用Spring.Net对我们有利吗？”

我认为您的问题的精神实质上更多地是质疑使用IoC/DI框架与根据需要手动管理依赖关系的好处。我的回应将更多地关注IoC/DI的原因和原因，而不是关于使用哪个具体框架。

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

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

从Silverlight角度来看，DI可以以各种方式使用。最明显的是定义View与ViewModels的关系。然而，更深入的是，您可以定义验证和RIA上下文依赖关系等。拥有配置类中定义的所有依赖关系，可以让代码免于需要知道如何获取/创建实例，而是关注使用情况。不要忘记容器可以根据你的配置管理每个对象实例的生命周期。因此，如果您需要共享某个类型的实例（例如Singleton，ManagedThread等），则可以通过声明与该容器一起注册的每个类型的生命周期范围来支持该实例。

我刚刚意识到此时我在咆哮，我很抱歉。希望这可以帮助！