spring.net有什么用？
我们正在使用 Silverlight 和 WCF 服务开发一个应用程序。使用Spring.Net对我们有好处吗？
We are developing an application using Silverlight and WCF Services. Is using Spring.Net is beneficial for us?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
>>> “使用 Spring.Net 对我们有好处吗？”
我认为你的问题的实质更多的是质疑使用 IoC/DI 框架与根据需要手动管理依赖项的好处。我的回答将更多地关注 IoC/DI 的原因和原因，而不是使用哪个特定框架。
正如 Martin Fowler 在最近的一次会议上提到的，DI 允许您将配置与使用分开。对我来说，将配置和使用作为单独的关注点来考虑 DI 是开始提出正确问题的好方法。您的应用程序是否需要为您的依赖项提供多种配置？您的应用程序是否需要能够通过配置修改行为？请记住，这意味着依赖关系在运行时解析，并且通常需要 XML 配置文件，这很好，因为无需重新编译程序集即可进行更改。就我个人而言，我不喜欢基于 XML 的依赖项配置，因为它们最终会被用作“魔术字符串”。因此，如果您最终拼写错误类名等，则存在引入运行时错误的危险。但如果您需要动态配置的能力，这可能是当今最好的解决方案。
另一方面，Ninject 和 StructureMap 等 DI 框架允许流畅的代码内依赖定义。您失去了动态更改定义的能力，但您获得了编译时验证的额外好处，这是我更喜欢的。如果您希望 DI 框架只是解决依赖关系，那么您可以从等式中消除基于 XML 的框架。
从 Silverlight 的角度来看，DI 可以以多种方式使用。最明显的是定义视图与视图模型的关系。然而，更深入地说，您可以定义验证和 RIA 上下文依赖项等。在配置类中定义所有依赖项可以使代码不需要知道如何获取/创建实例，而是专注于使用。不要忘记容器可以根据您的配置管理每个对象实例的生命周期。因此，如果您需要共享类型的实例（例如 Singleton、ManagedThread 等），则可以通过声明在容器中注册的每个类型的生命周期范围来支持这一点。
我刚刚意识到我在咆哮并且我道歉。希望这有帮助！
>> "Is using Spring.Net is beneficial for us?"
I think the spirit of your question is really geared more towards questioning the benefit of using an IoC/DI framework versus manually managing dependencies as needed. My response will focus more on the why and why not of IoC/DI and not so much on which specific framework to use.
As Martin Fowler mentioned at a recent conference, DI allows you to separate configuration from usage. For me, thinking about DI in the light of configuration and usage as separate concerns is a great way to start asking the right questions. Is there a need for your application to have multiple configurations for your dependencies? Does your app need the ability to modify behavior by configuration? Keep in mind, this means that dependencies are resolved at runtime and typically require an XML configuration file which is nice because changes can be made without requiring a recompile of the assembly. Personally, I'm not a fan of XML-based configuration of dependencies as they end up being consumed as "magic strings". So there's the danger of introducing runtime errors if you end up misspelling a class name, etc. But if you need the ability to configure on-the-fly, this is probably the best solution today.
On the other hand, there are DI frameworks like Ninject and StructureMap that allow fluent in-code dependency definitions. You lose the ability to change definitions on-the-fly, but you get the added benefit of compile time validations, which I prefer. If all you want from a DI framework is to resolve dependencies then you could eliminate XML-based frameworks from the equation.
From a Silverlight perspective, DI can be used in various ways. The most obvious is to define the relationship of Views to ViewModels. Going deeper, however, you can define validation, and RIA context dependencies, etc. Having all of the dependencies defined in a configuration class keeps the code free from needing to know how to get/create instances and instead focus on usage. Don't forget that the container can manage the lifetime of each object instance based on your config. So if you need to share an instance of a type (e.g. Singleton, ManagedThread, etc.), this is supported by declaring the lifetime scope of each type registered with the container.
I just realized at this point I'm ranting and I apologize. Hope this helps!
就我个人而言，我建议使用 Castle 或 Unity，因为我在这两种框架上都取得了巨大的成功，并且发现它们都是不同的、优秀的 IOC 框架。
除了 IOC 组件之外，他们还提供其他漂亮的工具（例如 Castle 中的 AOP、Unity 中的界面拦截），毫无疑问，您将来会发现它们的用途，并且从一开始就有一个 IOC 框架总是很糟糕比尝试改造它容易得多。
它的设置和配置非常简单，尽管我个人不太喜欢 XML 配置方式，因为其中一些配置文件可能会变成一场噩梦。很多人会告诉您，只有当您打算交换组件时才值得这样做，但为什么不这样做呢，以防万一您决定稍后需要这样做。拥有它但不使用它，比没有它但需要它要好。如果你担心性能下降，我在网络上的许多博客文章中看到人们比较各种 IOC 框架的速度，除非你正在创建脑部手术机器人或美国导弹防御平台，否则这不会是一个问题。
Personally i'd recommend using either Castle or Unity as i've had great success with both and found them both, while different, excellent IOC frameworks.
Besides the IOC component they also provide other nifty tools (AOP in Castle, Interface interception in Unity, for example) which you will no doubt find a use for in the future, and having an IOC framework in place from the start is ALWAYS a hell of a lot easier than trying to retrofit it.
It's incredibly easy to setup and configure, although personally i'm not a huge fan of the XML config way of doing things as some of those config files can turn into a total nightmare. A lot of people will tell you that it's only worth doing if you intend to swap components in and out, but why not just do that anyway IN CASE you decide you need to do that later. it's better to have it and not use it, than not have it and need it. If you're worried about perf hit i've seen on many blog posts around the web people comparing the various IOC frameworks for their speed and unless you're creating brain surgery robots or the US Missile defence platform it won't be an issue.
如果您想更改应用程序的大部分内容而不必重写构造函数，那么 DI 框架可能会很有用。例如，您可能想要使用将通过接口公开的彗星流服务，然后决定使用专用的消息传递系统，例如 MQ 或 RendezVous。然后，您将编写一个 Mq 适配器，该适配器尊重公共外观，只需更改 spring 配置以使用 Mq 实现而不是 Comet 实现。
但是出于对小马托尼的热爱，不要使用 Spring.Net 为每个视图创建 MVVM/MVP/MVC 绑定，否则您将进入一个痛苦的世界。
与 parcimony 一起使用时，DI 是一个很棒的工具，为了开发人员的理智，请不要最终得到 243 个 spring 配置文件。
A DI Framework might be of use if you want to change big chunks of your application without having to rewrite your constructors. For example, you might want to use a comet streaming service that you will expose through an interface, and later decide that you'd rather use a dedicated messenging system such as MQ or RendezVous. You will then write an adapter to Mq that respects the common facade and just change the spring config to use the Mq implementation rather than the Comet one.
But for the love of tony the pony, don't use Spring.Net to create your MVVM/MVP/MVC bindings for each and every view or you'll enter a world of pain.
DI is a great tool when used with parcimony, please don't end-up with 243 spring configuration files, for your devs' sanity.
使用 Spring.Net 等 IOC 容器是有益的，因为它使您能够通过交换应用程序接口的模拟或特殊测试实现来对 UI 的部分进行单元测试。从长远来看，这应该使您的应用程序对于未来的开发人员来说更易于维护。
Using an IOC container such as Spring.Net is beneficial as it will enable you to unit test parts of your UI by swapping in mocked or special test implementations of the applications interfaces. In the long run, this should make your application more maintainable for future developers.
我认为，如果您在代码中执行更多操作而不是使用标记进行绑定等，并且拥有 BAL/DAL DI 可以提供帮助，因为它可以注入正确的业务组件引用（作为一个示例）。 DI 还有许多其他实际优势，但是您必须在代码中做更多的事情，而在标记中做更少的事情。
I think if you do more in the code rather than using the markup to do bindings etc. and have a BAL/DAL DI can help there because it can inject the correct business component reference (as one example). DI has many other practical advantages, but then you have to do more in code and less in markup.