It’s been several months since I’ve posted an update on Siege.ServiceLocation. I’ve not been dormant over these last few months, but rather very active. I have a few updates I want to share with you guys. These have been a long time brewing. First and foremost…
Siege.ServiceLocation is now Siege.Requisitions!
Going with a more “Siege-like” theme in naming, I’ve decided to rename this project and others (we’ll get into that in a moment). This update is much, much more than a name change, however. The entire service location api has been streamlined and simplified. Siege is more than just a simple abstraction over IoC syntax, though it retains that quality. As a furtherance of previous posts, it has become a complete Type-Selection Framework, bundling all the requisite rules and algorithms for managing type mapping and selecting the corresponding type for a request. This is the cornerstone of the framework and will remain its focus.
However, there is more news.
What is this again?
I don’t blame you if you don’t recall — it has been a long time since my last post after all. So in short, Siege.Requisitions is a framework whose goal is to provide a simple and intuitive interface for using IoC frameworks. Its intent is to abstract away the majority of commonly used syntax to a single and consistent API. Its intent is to allow users to specify multiple implementations of a single interface and depend on the container to intelligently and intuitively select between them at runtime. Its intent is to leverage the existing functionality exposed by IoC frameworks will extending all of them with additional functionality. Its intent is not to prevent users from leveraging the abilities of whatever IoC they want to use.
In short, Siege.Requisitions is a Type-Selection framework that uses a very simple and streamlined API to abstract away other IoC frameworks to a single line of code, allowing users to swap between them seamlessly, or to migrate from one to another easily, all while leveraging the strength of each framework while enriching it with additional functionality, without preventing users from harnessing the power of whatever IoC they choose to use.
Siege.Requisitions IS an Inversion of Control framework
Or at least, it can be. True to our design philosophy, we have focused each component to its specific problem domain. I truly believe that existing IoC frameworks overstep their boundaries by tightly-coupling their registration, selection and resolution responsibilities. Siege.Requisitions splits these responsibilities up between its components and allows consumers to provide their own implementations and rules for each area of responsibility. By doing this, Siege.Requisitions can function completely as a simple type-selection framework that extends other IoC frameworks, or it can act as a standalone IoC framework. Siege.Requisitions provides its own type-resolver, optimized for use with our framework and extremely performant versus other resolution containers.
Our focus has always been and continues to be simplicity, understandability, usability and consumability for our users.
Siege has its own website
I will continue to make periodic updates about Siege at Los Techies but will be more active on the Siege website, which will be extended beyond what it is now (just a wiki). I don’t want my sole focus here to be this project. I have a lot of other things I’m working on and want to share, first and foremost, the work I do using MonoTouch. Which brings me to …
Siege.Requisitions is fully functional on the MonoTouch framework
I have enjoyed working with MonoTouch so much that I wanted to build support for it. When using Siege as an IoC, with its own Type Resolver, special support has been added to work specifically with MonoTouch. New development on Siege is targeting the .NET 4.0 framework but I will continue to support the .NET 3.5 framework with bug fixes and specific functionality for MonoTouch. I am serious about providing framework support for this awesome tool and cannot speak highly enough about it. I consider it just as important to support as the .NET framework itself.
Other Siege Projects!
I’m pleased to share a few other project-related updates. On the Siege Website you will notice two new projects.
- Siege.Foundry – This is an abstraction over IL that allows consumers to define algorithms by which types can be dynamically created. You can define the type you want, name it, add constructors and define their behaviors and add methods and define their behaviors. Support is there for inheritance and overriding of methods. This is currently in alpha but I am switching focus to flesh this out much more. Siege (and some of my other unreleased projects) use this framework for several different purposes.
- Siege.Arsenal – This is a framework that proxies objects, currently based on decoration by attributes. This is also in alpha and will also be extended much more (as it uses Siege.Foundry for its proxying duties)
Siege.Requisitions will continue to receive periodic updates from me. I’d love to hear feedback from you guys, so feel free to contact me via e-mail or twitter if you have any feedback. There is a roadmap for this project, which is on the website, and I will continue to post there and here about updates and progress as it is made. There have been a host of additional features and improvements too numerous to mention here. So go to the website and check it out. .NET 4.0 assemblies are hosted on the download page (.NET 3.5 downloads will be added soon!)
Post Footer automatically generated by Add Post Footer Plugin for wordpress.