Agatha 1.0 Beta 2 Is Out
Posted by Davy Brion on November 29th, 2009
I just released Agatha 1.0 Beta 2… while the changes aren’t spectacular, i considered them important enough to release a new version.
Here’s the changelog:
- Logging in the servicelayer now happens through the Common.Logging instead of using log4net directly… which means you can use whatever logging library you prefer
- (Breaking Change): If you want to pass your container instance to an Agatha container wrapper, you have to pass it to the constructor of the wrapper, and then pass that IContainer instance to your ServiceLayerConfiguration or ClientConfiguration instance before initializing
- Added Agatha.Unity and Agatha.Unity.Silverlight
- Added simple example of Agatha in use, with a small service layer, an IIS host for the service layer, a .NET client which performs a synchronous and an asynchronous client, and a Silverlight client which also performs an asynchronous call
The 2 most important changes are obviously that you can now integrate your own IOC container more easily and cleanly, and that you can use whatever logging library that you prefer. If you download the source of beta 2, you’ll also get the example solution which shows you how easily you can start using Agatha in your projects.
You can download the bits here.
November 30th, 2009 at 11:28 am
[...] Agatha 1.0 Beta 2 Is Out – Davy Brion announces the release of the second beta of Agatha 1.0, the open source version of his workplaces Request Response Service Layer implementation, with improvements to logging, IOC support, examples and the introduction of Unity support for both standard and Silverlight. [...]
November 30th, 2009 at 10:27 pm
Davy,
Have you looked at http://www.codeplex.com/CommonServiceLocator? Nicely avoids having to cook up an IOC interface.
November 30th, 2009 at 10:30 pm
@John
http://davybrion.com/blog/2009/11/integrating-your-ioc-container-with-agatha/
i did, and no, it doesn’t avoid it
November 30th, 2009 at 10:33 pm
Ignore my last comment… I was reading in reverse chronological order. I’d have preferred if they included the Release method, which could easily be left blank for containers that don’t use it. (Like IServiceProvider in MvcContrib, but again, that doesn’t have registration.)
As far as registering components, I like not having that in the interface and letting the bootstrapper code handle the registration in the same place it sets the ServiceLocator Current container.
November 30th, 2009 at 10:43 pm
it depends… if a library wants to take responsibility of registering the components for you so that you don’t have to (and can’t get it wrong…), then the interface is useless… oh well
December 3rd, 2009 at 7:17 am
Kinda off topic, but with your response classes in the real world… do you make them implement INotifyPropertyChanged so you can bind them to the UI? If so, do you do the standard RaisePropertyChanged(“propertyName”) in all of your setters or do you use some sort of special custom method(s) like SetValue() to get rid of the “magic strings”, or maybe some AOP to completely avoid having to do it.
December 3rd, 2009 at 9:15 am
we implement INotifyPropertyChanged like this:
http://davybrion.com/blog/2009/08/refactor-safe-implementation-of-inotifypropertychanged/
our response types do not implement INotifyPropertyChanged, nor do they contain anything else that is UI specific for that matter