Agatha 1.0 Beta 2 Is Out

7 commentsWritten on November 29th, 2009 by
Categories: agatha

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.

« Integrating Your IOC Container With Agatha400 Posts »

This entry was posted on Sunday, November 29th, 2009 at 22:31 and is filed under agatha. You can subscribe to any comments to this entry via RSS 2.0. You can leave a response, or trackback from your own site.

  • Pingback: Reflective Perspective - Chris Alcock » The Morning Brew #487

  • John

    Davy,

    Have you looked at http://www.codeplex.com/CommonServiceLocator? Nicely avoids having to cook up an IOC interface.

  • http://davybrion.com Davy Brion
  • John

    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.

  • http://davybrion.com Davy Brion

    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 ;)

  • Josh

    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.

  • http://davybrion.com Davy Brion

    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 :)

Meta

Recent Posts

Categories

Archives