Is Spring.NET development left behind modern rich client development

[sroth]

Hi there,

I have a quite provoking question. While reading the different forums on this site I got the impresseion that there's not much development going on on behalf of direct support of state of the art technologies: There are some tiny hints for using WPF, a Silverlight forum doesn't even exist.
I was just wondering whether this isn't interesting at all for the Spring.NET users or whether the Spring.NET framework development has become stuck at a level of .NET technonogy used four years before?
I mean there are questions of guys asking how to use WCF Ria services in combination with Spring.NET or whether anybody has already had any ecxperience with using PRISM with Spring.NET - but there are merely any useful answers to all these topics.
At my company we're evaluating whether to use Spring.NET with all the cool features like direct ActiveMQ-support, service registry, AOP etc. but the impression remains that Spring.NET seems to be stuck somewhere four years before. I don't want to blame anybody or create any prejudices. I think it's still a great framework but I was asking myself whether I'm the only person having doubts? Perhaps someone could give me a light what's going on with state of the art rich client support and Spring.NET?
Thanks!

Stefan

[Mark Pollack]

Hi,

There are no big plans for rich client support. There is the simple integration between PRISM and all DI containers via the Service Locator project, and from what people have told me, that is enough for them. I personally don't see myself developing out something like 'Spring MVVM' but I certainly don't rule out others contributing to Spring in this area for example and would quite welcome it.

I have had requests for Silverlight4 compatibility and time permitting it is something we will look into. Web applications, ASP.NET and ASP.NET MVC are where more features are coming in terms of UI development.

Do you see the lack of rich UI support as something other application frameworks are providing? I haven't seen that so much but I certainly could have missed it.

Spring has always had a server side bent to it so that reflects the the bias in its feature set. Also, I am more of a server side/web guy than rich client even though oddly enough I started Spring.NET to help address developmenet issues in a WinForm application I was developing.


In terms of what we are planning to do. Catch up to the other containers in terms of alternatives to container configuration. Sadly, the POC code for what was posted on Eric's blog that uses 'plain old code' to configure the container is ~3 years old. That functionality is a high priority. See these links for more information.

http://eeichinger.blogspot.com/2009/12/merry-xmlless-codeconfig-for-springnet.html

https://src.springframework.org/svn/se-config-net/trunk


There has been work going on for quite a while on a .NET version of Spring Integration. I can see integration with the Rx Framework happening quite naturally in this space.

http://www.springsource.org/spring-integration

https://src.springframework.org/svn/se-springintegration-net/trunk

And with the recent aquisitions of the commerical entities behind RabbitMQ (http://www.rabbitmq.com/) and Gemstone (http://www.gemstone.com/) / Gemfire (http://www.gemstone.com/products/gemfire) (closed source) by SpringSource, there will be work on AMQP and data grid features. (not specific to rabbit or gemfire though) You can get a sneak peak at the AMQP work here - https://src.springsource.org/svn/se-amqp/trunk


Please let me know what specific needs you have in the Rich UI space. Creating a Silverlight forum is a good idea to initiate converation on that area... what version of Silverlight did you have in mind?

Mark

[sroth]

Hi Mark,

thanks for those clarifications. I had the same impression that the focus of Spring.NET is more or less on middleware. This means that you'd have to use an extra framework for GUI in case you wanted to create some rich clients in order to visualize your data. This is a quite interesting scenario, though. Should be possible for PRISM, but haven't found any success messages on the net yet. I guess we could do this (as Prism claims to be IoC-independent), but it's still a risk if you're the first one trying...
Well, If I had three wishes, one of them would be direct support of rich client development in Spring.NET, such as direct support for building up frames/views/regions etc. for WPF and/or Silverlight. I'd fancy support for the newest version of Silverlight, currently 4.0. But maybe this is too much and should always be separated? What do you think?

Cheers,

Stefan

[bbarvish01]

Stefan,

It appears to me that most users of Prism will stick to the Unity container which ships with the Prism build. The reason for that is because they look at the Bootstrap class and are afraid to make the jump to Spring. I'd spent about 2 days and have a fully functional WPF 4 with Prism and CommonServiceLocator.SpringAdapter as the bridge between the container agnostic Prism code and the Spring Container. The pieces are there for you and your team to accomplish anything you need to. All you need is a bit of courage, a good cup of coffee, a bit of patience and a few Ben Harper albums.

I found the biggest challenge with inserting instances into the container and will offer you the code to do so:


protected void RegisterTypeIfMissing(object target, string name, bool registerAsSingleton)
{

_logger.LogTrace(string.Format("Registering object named: <{0}> as singleton: <{1}>", name, registerAsSingleton));

if (Container.ContainsObject(name))
{
_logger.LogInfo(String.Format("Type <{0}> is already registred ", target.GetType()));
}
else
{
if (registerAsSingleton)
{
Container.RegisterSingleton(name, target);
}
else
{
var objectDefinitionFactory = new DefaultObjectDefinitionFactory();
var builder = ObjectDefinitionBuilder.RootObjectDefinition(objec tDefinitionFactory, target.GetType());
builder.SetSingleton(false).SetAutowireMode(AutoWi ringMode.Constructor);

Container.RegisterObjectDefinition(name, builder.ObjectDefinition);

}
}
}

WPF is an amazing desktop development platform and spring's .net implementation provides all the necessary tools to take the headaches out of creating and wiring up objects, as well as many other functionality offered by the framework.

[Steve Bohlen]

bbarvish01:

Is this code something that you would consider contributing to the Spring.NET project? I'm sure that other users would be interested in taking advantage of it for their own WPF applications.

We (obviously) accept patches but even contributing your mentioned example as a new available 'sample' Spring.NET application would be valuable to others to be able to review/investigate in its entirety.

Thanks and please let me know your thoughts on this~!

Regards,

-Steve B.
SpringSource

[CyberPunk]

Hi there,

I have a quite provoking question. While reading the different forums on this site I got the impresseion that there's not much development going on on behalf of direct support of state of the art technologies: There are some tiny hints for using WPF, a Silverlight forum doesn't even exist.
I was just wondering whether this isn't interesting at all for the Spring.NET users or whether the Spring.NET framework development has become stuck at a level of .NET technonogy used four years before?
I mean there are questions of guys asking how to use WCF Ria services in combination with Spring.NET or whether anybody has already had any ecxperience with using PRISM with Spring.NET - but there are merely any useful answers to all these topics.
At my company we're evaluating whether to use Spring.NET with all the cool features like direct ActiveMQ-support, service registry, AOP etc. but the impression remains that Spring.NET seems to be stuck somewhere four years before. I don't want to blame anybody or create any prejudices. I think it's still a great framework but I was asking myself whether I'm the only person having doubts? Perhaps someone could give me a light what's going on with state of the art rich client support and Spring.NET?
Thanks!

Stefan

Stuck in the past just because there is no support for rich-clients? What about all the stuff (messaging,gemstone,etc) ?

In the end, even the richest-of-the-richest user interface will have to interact with a a backend. Guess what you can use to build that backend? :-)