SpringFramework.NET Introduction.
I was about 30% of the way writing the introduction to SpringFramework.NET for newbies, when it occurred to me "..Surely I'm not the only one on the planet whom thought this would be a good use of my time.."
I then hit Live.com and began to search around and came across this site:
https://www.gotnet.biz/IntroductionToSpringFactoriesAndAOP.ashx
Not only is it a great starting point for SpringFramework, it also offers a consolidated view of what the Framework has on offer. I mention this as with the maturity of MVC Framework coming out, combining SpringFramework with the MVC might not be such a bad idea? (each to their own anyway).
Scope out the above link, assess the framework on whether it suites your own problems and remember that a framework is there to help guide you through a certain type(s) of methodologies that you wish to apply to your code base.
They aren't a rule book, bible or fashion accessory. I mention this as in my experience of the past, I've watched developers use 115 Lines of code to write "hello world" where 2 lines would of be sufficient (all because they bought into the framework trap).
It also plays well with ASP.NET AJAX (Important for me as I'm getting really lazy with my code these days! :D).
** Update: **
Some other links:
- Q&A
https://www.infoq.com/articles/SpringDotNET-QnA - Spring ASP.NET Page Trace Aspect
https://softwaredevscott.spaces.live.com/blog/cns!1A9E939F7373F3B7!341.entry - Use Spring.NET to enable Dependency Injection on a ASP.NET MVC Controller
https://weblogs.asp.net/fredriknormen/archive/2007/11/17/asp-net-mvc-framework-create-your-own-icontrollerfactory-and-use-spring-net.aspx
Comments
- Anonymous
November 18, 2007
Can you provide us with your take on the differences between Spring.NET and the Castle Project (good and bad)? I've recently started looking at the Castle Project and it certainly is very appealing and I was wondering how it stacks up against Spring.NET. Also some caveats with using DI that users need to be aware of is: 1) no more F12 :( since objects passed around as interfaces, so VS doesn't know the implemented object, (it would be awesome if it could that); 2)the other issue I have with it, is that all DI objects must be public. In a class library I want to hide some implementation say the Data Access Layer, but still want DI at the class library level. Haven't been able to figure that out yet (if possible).