What is the use of spring.net?

Question

We are developing an application using Silverlight and WCF Services. Does Spring.Net use beneficial to us?

Answer 1

→ "Does Spring.Net Useful for Us?"

I think the spirit of your question is really more focused on the question of the benefits of using the IoC / DI infrastructure and manual dependency management as needed. My answer will be more about why and why there is no IoC / DI, and not so much about which specific structure to use.

As Martin Fowler noted at a recent conference, DI allows you to separate configuration from use. For me, thinking about DI in the light of configuration and use as separate issues 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 application require the ability to change configuration behavior? Keep in mind that this means that dependencies are resolved at runtime and usually require an XML configuration file, which is good since changes can be made without having to recompile the assembly. I personally am not a fan of XML-based dependency customization, as they are ultimately consumed as "magic strings." Thus, there is a danger of runtime errors if you end up sealing the class name, etc. But if you need customization on the fly, this is probably the best solution today.

On the other hand, there are DI frames, such as Ninject and StructureMap, which allow you to freely define dependency definitions in your code. You lose the ability to change definitions on the fly, but you get the added benefit of checking compile time, which I prefer. If all you want from the DI framework is to allow dependencies, you can exclude the basics of XML from the equation.

From a Silverlight perspective, DI can be used in a variety of ways. The most obvious is defining the relationship of Views to ViewModels. However, delving deeper, you can define validations and context-dependent RIAs, etc. Having all the dependencies defined in the configuration class, this code does not require knowing how to get / create instances and instead focus on usage. Remember that a container can control the lifetime of each instance of an object based on your configuration. Therefore, if you need to split an instance of a type (e.g. Singleton, ManagedThread, etc.), this is confirmed by the declaration of the scope of each type registered in the container.

I just realized what I was saying now, and I apologize. Hope this helps!

Answer 2

Personally, I would recommend using Castle or Unity, as I had great success with both and found them both, while different, different IOC frameworks.

In addition to the IOC component, they also provide other excellent tools (for example, AOP in the lock, interception of the interface in Unity), which will undoubtedly be used in the future, and from the very beginning of the IOC foundation, ALWAYS it is much easier than trying to modify his.

It is incredibly easy to set up and configure, although I personally am not a huge fan of the way to configure XML, as some of these configuration files can turn into a complete nightmare. Many people will tell you that this is only worthwhile if you intend to rearrange the components back and forth, but why not just do it anyway. In case you decide that you need to do this later. it is better to have it and not use it, than not to have it and need it. If you are worried about the perfectionist hit I've seen in many blog posts around the world that compare the various IOC frameworks with their speed, and if you do not create robots for brain surgery or the US missile defense platform, this will not be a problem.

Answer 3

Using an IOC container such as Spring.Net is beneficial because it allows you to unit test portions of your interface by replacing in mocked or special test implementations of application interfaces. Ultimately, this should make your application more convenient for future developers.

Answer 4

The DI framework can be useful if you want to change large chunks of your application without rewriting your constructors. For example, you can use the comet streaming service that you open through the interface, and then decide that you prefer to use a special messaging system such as MQ or RendezVous. Then you write an adapter for Mq that respects the overall façade, and just change the spring configuration to use the Mq implementation, not the comet.

But for the love of Tony Pony, don't use Spring.Net to create MVVM / MVP / MVC bindings for each view, or you will end up in a world of pain.

DI is a great tool when used with the site, please do not create 243 spring configuration files for the reasonableness of your developers.

Answer 5

I think that if you do more in code, rather than using markup, do bindings, etc. and have BAL / DAL DI can help there, because it can give the correct business component link (as an example). DI has many other practical advantages, but then you need to do more code and less markup.