One of the things I really wanted to do when I set out to create the ServiceLocator in Siege.Requisitions was to create a container that could map an interface to multiple types, and then at runtime, automatically figure out which one of those types I really wanted. To accomplish this, I put at it’s core a small rule engine to allow users to create rules that would help the container understand how to pick implementations. It works great — but there’s one problem. You have to specifically tell it what you want. That’s hardly much better than resolving the type directly; you have to program intent directly into your application, and you carry around references to IServiceLocator.

Very ugly.

I keep coming back to the original premise … I want the container to figure it out for me. I want to explain to the container what I want it to do, and under which conditions. Then I want it to figure it out for itself at runtime by understanding the state of the application, the user session, whatever I have explained to it. I want a smart container. But the problem is, most containers are dumb. You map an interface to a type — thats it. You want multiple types? Register them with names to distinguish them. Register different “profiles” to instruct the container to run in certain modes. Create child containers.

I just didn’t feel like those solutions worked well for me. I want a smart container that can figure it all out. I don’t want to spend time building families of containers and wiring it all together and telling them how to interact. I don’t want to have to make my application look up values by a name, or set my container into a certain “profile mode”. I want to focus on my application. I want to explain my scenario to the container and move on and not think about my container anymore.

A practical example

As I mentioned in my previous post, we encounter this scenario in our every day development at my company. Where I work, we integrate with a lot of partners. There are a lot of commonalities between these vendors and we have abstracted them out dutifully into interfaces with multiple implementations. Basic abstraction and polymorphism. We routinely have scenarios where user input/selections on a UI translates into a vendor call. Ultimately, this means resolving a specific implementation of an interface to send or request data from that vendor.

We have our registrations set up with rules like so:

serviceLocator.Register<Singleton>(Given<IExampleService>.When<SelectionType>(selection => selection == SelectionType.OptionA).Then<OptionAService>();
serviceLocator.Register<Singleton>(Given<IExampleService>.When<SelectionType>(selection => selection == SelectionType.OptionB).Then<OptionBService>();

For the sake of this example, SelectionType is an enum representing a vendor we integrate with. Implementations of IExampleService contain code that we use to integrate with those vendors. The registration API allows you to specify the lifestyle with the method call (in this case, singleton). And with those registrations in place, you’d see controller code like this:

public class SampleController : Controller
{
     private IServiceLocator serviceLocator;
    
     public SampleController(IServiceLocator locator)
     {
            this.serviceLocator = locator;
     }

     public ViewResult Foo(SelectionType selectionType)
     {
           IExampleService service = locator.GetInstance<IExampleService>(new ContextArgument(selectionType));
           //invoke methods on service
     } 
} 

Like I said, ugly stuff. In this example, we get a reference to the service locator, pass in some context to help the container identify which rule applies so it knows which type to create. I don’t want to carry around that reference to IServiceLocator, and I don’t want my controllers having to understand how to help the container to select the rule that applies based on user input.

Like I said, I want a smart container. Turns out the solution was pretty easy to implement, and didn’t even require me to change how Siege works!

Introducing Awareness.Of<T>

Siege simplifies thing for consumers by exposing only one method to do registrations — I call it Register (novel, I know). Register takes in instances of IRegistration, or Action<IServiceLocator>. There are several different syntaxes available to help you do registrations … Given<T>, which helps you register individual types … Using.Convention<TConvention> which allows you bundle registrations together for reuse, and now … Awareness.Of<T>, which tells the container how to figure out the things it needs to evaluate its rules on its own.

This abstraction allows consumers to extend the Service Locator easily — by providing your own implementation of IRegistration, the container understands how to handle your new and unique registration type. To prove this premise, I add all new functionality to Siege.Requisitions.Extensions without extending the core framework. It is completely pluggable. But, that’s a tangent, and I’ll cover it more in some other post.

With Awareness, we have a smart container, which can identify the rules associated with a requested type and use its own awareness to determine validity of those rules.

How does it work?

Awareness.Of<T> works like this: When you resolve a type, the container looks up all rules associated with that type. In our example, it receives rules based on SelectionType. If the container is “Aware” of SelectionType, it will automatically use that awareness to find the current SelectionType value and then give it to the rule engine to evaluate. It continues this process until either a rule is satisfied or no rules match.

Awareness.Of<T> takes a delegate as an argument. This delegate is a Func<T> which tells the container how to get an instance of T to use in rule evaluation. For our MVC applications, we have used Awareness.Of<T> to make our container aware of the Model Binding mechanism in ASP.NET MVC, which it uses to pull data into an object like model binding for controller actions done (form data, query string data, etc), to make our container aware of any configuration files, to make it aware of the session, to make it aware of a wide variety of things. The container becomes more intelligent the more aware it becomes; Your other processes cease to depend on the container at all and cease to have to explicitly direct the container to make decisions.

It all happens naturally, and intuitively.

Making your container contextually aware

To make your container aware is very easy. To follow with our example, I will show you how we’ve made our container aware of the model binding system in ASP.NET MVC. This registration is from code in the Siege.Requisitions.Web.dll file. It’s very simple, just provide a registration like this:

serviceLocator.Register(Awareness.Of(ModelBinding.For<SelectionType>().UsingDefaultBinder());

This registration instructs the service locator to use the default model binder to pull create a SelectionType object. There are also methods on ModelBinding.For<T> which allow you to specify a custom binder (if, for example, you need to look an object up by ID before evaluating it with a rule). 

Our example, revisited with Awareness.

So here’s what the whole thing looks like with awareness. I will also use controller action injection, as I covered in my last post.

//from global.asax.cs, or wherever you initialize the container

serviceLocator.Register<Singleton>(Given<IExampleService>.When<SelectionType>(selection => selection == SelectionType.OptionA).Then<OptionAService>();
serviceLocator.Register<Singleton>(Given<IExampleService>.When<SelectionType>(selection => selection == SelectionType.OptionB).Then<OptionBService>();
serviceLocator.Register(Awareness.Of(ModelBinding.For<SelectionType>().UsingDefaultBinder()); 

public class SampleController : Controller
{
     public SampleController()
     {
     }

     public ViewResult Foo(IExampleService service)
     {
           //invoke methods on service
     } 
}

Looks much cleaner, don’t you think? All properly decoupled and automatically done for you. The best part is — it works with whatever container you’re already using. One of the other priorities I had when I started Siege was to be a value-added proposition for existing containers. If you use Windsor, StructureMap, Unity, whatever… Siege integrates seamlessly with them and makes them smarter. It adds additional abilities to what those containers can already do.

Happy Coding!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Recently, I bought an iPad and decided to try my hand at objective-C. It was a pretty fun experience but as I began to think of apps that I’d actually want to write, I knew of a lot of open-source tools (either written by me or others) that I’d want to use. I definitely didn’t want to try re-writing them in objective-c. I had remembered a coworker of mine mentioning MonoTouch to me in the past as a C# compiler for the iPhone so I decided to check it out. Sure enough, they target both the iPhone and iPad. So I decided to download it and give it a try.

This guide is intended to help you get started with a project you can deploy to your device. If you want to simply develop with the simulator, not all of these steps will apply to you. You can simply scroll down to ‘Your first Monotouch application’ and read from there.

Before We Get Started

There has been a fair amount of concern and discussion regarding the apple developer agreement for iPhone OS 4.0. This had put me off for a while as I didn’t want to spend a lot of time working on an app that ultimately wouldn’t be approved. Having monitored the community for a few months, it appears that people are still getting their apps approved with regular frequency. This isn’t to say that Apple won’t one day decide to start rejecting apps — but it is a promising sign nonetheless. The people at MonoTouch certainly don’t think this is the end for their platform, but it’s up to you to decide if you want to take the risk. I plan to, not only because I like writing code in C#, but because I want to be able to take advantage of several .NET features supported by MonoTouch — WCF and Reflection, for example, and because I want to be able to use certain technologies like an IoC container.

Getting Started (what will I need?)

• A mac
• XCode
• MonoDevelop (http://monodevelop.com/Download)
• MonoTouch (http://monotouch.net/DownloadTrial)
• An Apple Developer Key (http://developer.apple.com/iphone/index.action)

Once you’ve downloaded MonoDevelop and MonoTouch and installed them, it’s time to get your Apple Developer key. Follow the above link and begin enrollment — you’ll need to select “iPhone Developer Program” as your development program. You’ll also need to enter the pertinent required information (billing/contact information). Agree to their developer terms (“I agree to sell my soul to Apple…”) and head to their checkout process. The privilege of being an apple developer runs about $99 (plus tax), so be prepared to fork over some money if you want to do anything more than develop on a iPhone or iPad simulator, and if you ever want to put your app on the market. Once you’ve placed your order, wait for your e-mail to arrive. For me, this took a couple of hours. They say it can take up to 24, so try to be patient.

But to be honest, the process wasn’t painless for me. I got my activation code, tried to verify and got this dreadful message:

“We are unable to activate your Apple Developer Program membership.”

Unfortunately that set this post back a few days while I waited through the weekend to be able to call up their support number and get things settled. Luckily they said they could resolve it on their side and everything got worked out for me. So, now that I have my key, things can move forward!

Provisioning your apps

Before you can deploy with MonoTouch to your iPhone or iPad, you have to provision your environment for deployment. Apple’s process requires a lot of manual work, which I will walk you through below. They also include videos on their site to walk you through it. This will install the necessary keys on your machine that will be used to sign and deploy your code. To begin this process, you will need to go to the iphone developer center (developer.apple.com) and request a certificate. To do this, you first need to make a certificate request from the keychain on your mac.

How to create a certificate request

Go to Finder, then Applications, then Keychain Access. Once this comes up, we’ll need to check the preferences. In the menu, go to Keychain Access, and then Preferences. Click the Certificates tab and ensure that both Online Certificate Status Protocol and Certificate Revocation List are set to ‘off’. Once this is done, close the preferences window. Now, in the menu, go to Keychain Access, and then Certificate Assistant, and then Request a Certificate from a Certificate Authority. We will use this application to generate a certificate request to submit to Apple.

Put in the e-mail address that you used to sign up for the developer program, and put in your name. Select “save to disk” and “Let me specify key pair information”. Click continue and select a location to save the request to. In the next menu, ensure the key size is 2048 bits using the RSA algorithm. Click continue to finish the process.

Requesting a certificate from Apple

Go to the developer portal and select the ‘Certificates’ menu option on the left. You should see an empty list in the ‘Development Tab’ and a ‘Request Certificate’ button. Click the button, and upload the certificate request you generated before. You will be e-mailed a notification from Apple once you have done this. After a short amount of time, your request should be approved. Once it has been approved you should be able to download the certificate from apple. Once you have done this, open the certificate to have it automatically added to your keychain in the Keychain Access program.

Adding your device for deployment and debugging

After you have gotten your certificate approved and added to your keychain, we will need to set up your device for deployment. Attach your iPod, iPad or iPhone to your mac and open iTunes. In the ‘Devices’ section, select your device to view the summary for it. Click the ‘Serial Number’ label to reveal your identifier, which we will need to enter into the apple portal. Once you have revealed it, select the ‘copy’ option in the edit menu. Go to the developer portal and select the ‘Devices’ link in the left menu. Once the ‘Devices’ page has loaded, click the ‘Add Device’ button in the upper left. Enter a name for your device, and then paste the identifier we copied from iTunes. Click submit to add the device. 

After you have added your device, you will need to generate an app ID for your application. App IDs are used for a few different purposes (communicating with hardware, supporting in-app purchases, etc), and is a required part of your application setup. Click on the ‘App IDs’ link on the left menu, and then click the ‘New App ID’ button.  You will need to add a decription and then put in your app id suffix. Apple recommend you do a reverse domain setup. Fill in the required fields and click ‘submit’.

Once you have completed these steps, you’ll be ready to create a provisioning profile. Click the ‘provisioning’ menu option on the left menu and then ‘New Profile’ when the page loads. Enter a profile name and then select your certificate, appID and device and click submit. You will be taken back to the provisioning page where you can then download your profile. If the status says ‘in progress’, give it a minute and refresh the page. Download the profile to your mac.

Setting up MonoTouch and your Application for Deployment

Now that you have all the requisite parts, you are ready to set up MonoTouch to deploy to your device. First, you will need to install the provisioning profile you just created. Double-click the profile to open it in XCode. It should automatically be installed from there, and you can close XCode once that is complete. 

Your first MonoTouch application

Until this point we’ve focused on the logistics of getting everything set up. While this was not strictly necessary if you only wanted to do development with the simulator, it is necessary if you want to deploy your application to your device. Open MonoDevelop and start a new project. Expand the C# section, and select the iPhone and iPad node. Select either the iPhone or iPad window based project (I am using the iPad project). Name your application — I am naming mine Test Application — and click the ‘Ok’ button.

Once your project is set up, you can double-click the MainWindow.xib file to bring up the interface builder. I’m not going to go into too much detail here, but basically you will want to put something on the view to show that your application is starting and displaying correctly. I put a label on the page with “Hello World!” as the text. To run this in the simulator, go to the ‘Run’ menu item and select ‘Run’. It will compile and run the application in the simulator. Cool, huh?

Deploying your app to your device

This is all good and fine, but lets get it deployed on your device! Luckily, MonoTouch should automatically pick up the required information now that it is installed on your mac. But if it doesn’t, follow these steps:

Go to the ‘Project’ menu item, and select your projects options. For me, this is called Test Application Options. If you named your solution differently, it will be different. The options window will open, and under the ‘Build’ section, click the ‘iPhone Bundle Signing’ item. Select the identity you set up with apple from the ‘Identity’ drop down and then select the provisioning profile you set up with apple from the ‘Provisioning profile’ drop down and click the ‘OK’ button.

Finally, you will need to set the build configuration to debug|iPhone. This will direct MonoTouch to build and deploy your application. Go to the ‘Run’ menu option and select ‘Run’. You may get a message that says ‘codesign wants to sign using key (key name) in your keychain’ … select ‘Always Allow’. Once it completes, you will get a window that says the app has been built and deployed to your device. Close this window, and start your device. Scroll to the app and touch it. It should start, and once started, you should see a ‘Hello World!’ message.

Getting started with MonoTouch is very easy and I am very pleased with how well they integrate MonoDevelop with the interface builder, the device simulator, and the device deployment process. Setting up with Apple is a very tedious process, but I am glad to see they did not carry this over into MonoDevelop or MonoTouch. 

If you have any questions or problems, please leave a comment and I will do my best to help out.

Happy coding!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

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

The address is http://www.dotsiege.net/ and the repository is at http://github.com/MarcusTheBold/Siege

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)

Looking Ahead

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.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Siege.ServiceLocation isn’t an abstraction, it’s a decoupling.

Siege.ServiceLocation isn’t just about contextual
registration/resolution (though that was the initial impetus). It’s not
about resolution at all. It’s about expressing registration. It’s about
adding functionality to ALL containers. There are a few things that I
am trying to accomplish with this library. First, I want to decouple
registration from resolution. That’s not to say I want to abstract how
each container’s registration is performed; I want them decoupled completely. Second, I want my library to be functionally compatible with existing frameworks (see Siege Design Philosophy
for more details). This means whatever Siege.ServiceLocation can do,
all the frameworks it integrates with can do. Third, I want it to be
easy. Outside of Ninject (which I think is a wonderfully built IoC), I
think the others fail the third criteria. I’ve worked with them all. I
know the differences. They each have distinct problems. And I don’t
think it has to be that way.

Inversion of Control containers should be about resolving types

Not about registering types. Registration is a way of instructing an
IoC how to resolve a type. It’s not what the IoC is built for, it’s a
way of expressing what the IoC needs to do. Each IoC has a different
way of accomplishing the same thing. I’ve been told that choosing an
IoC is about evaluating the strengths and weaknesses of each framework
and picking the one that suits your needs.

What? If an IoC is there to resolve types and their dependencies, to
provide a mechanism to help you decouple your code, then how can there
be strengths and weaknesses in each framework? Is it in terms of how
efficiently they perform the task? Is it in terms of they internally
manage resolution?

Or is it in terms of what their registration syntax allows you to
do? Is it in terms of how you express your goal? Is it in terms of the
instructions the container understands when it tries to resolve a type?

These are all rhetorical questions. The point is to look at the
problem differently than has been traditionally done. To my mind, there
is a clear seperation of concerns between the responsibility of
registering types and the responsibility of resolving types. I think an
IoC should specialize in resolving types and their dependencies, not
specialize in expressing how to resolve types and their dependencies.

Siege.ServiceLocation is not an IoC

It’s a coordination mechanism for an IoC container. Think “one level
above” the container. Rather than instructing an IoC container how to
resolve your type, you instruct Siege.ServiceLocation. It then in turn
knows how to interact with the underlying framework to get what you
want. It tracks the conditions and criteria. It makes all the requests
necessary through the underlying framework to get your objects
constructed. Think of it as a proxy with an adapter. The goal is to
track runtime conditions to facilitate the selection of an appropriate
interface. To enable this functionality WITHOUT having to force you to
use a specific framework. Where the IoC container specializes in
resolution, Siege.ServiceLocation specializes in registration and
communicating requests to the IoC container.

The reason that each IoC framework has strengths and weaknesses is
because each IoC has it’s own way of trying to go about describing how
they want things resolved. That means that some of them can interpret
certain resolution instructions. Others interpret their own resolution
instructions. That’s not the point of an IoC, and it’s no wonder they
all do it differently and each has their own strengths and weaknesses.

If we move the registration expression above the container that
performs resolution, we can decouple these two concepts. Then, as long
as the component that understands registration can express instructions
to the component that performs resolution, all containers can suddenly
benefit from these collective strengths. We remove the need for
containers to worry about these concerns. We remove the need for
developers to do an analysis of what “features” a container supports.
We remove the need for people to make trade-offs on what strengths they
gain, what weaknesses they are burdened with and what features they
lose out on when choosing an IoC framework.

The Least Common Denominator

In my brief conversation with Chad, he pointed out that most
abstraction attempts only manage to accomplish the Least Common
Denominator of all frameworks and wind up gutting the potential of each
of the frameworks they integrate with. I understand his point, but I
think this is fundamentally different. The desire is NOT to limit you
to what all frameworks have in common, but to allow people to use
functionality that may NOT exist in all frameworks. A primary example
of this is contextual resolution. Several IoCs can do this to some
extent or another, based on very narrow criteria. Some of them can’t do
it at all. None of them can respond to evolving runtime conditions when
selecting an implementation of a requested type.

When combining these containers with Siege, suddenly all of them
gain this ability. This is because Siege understands both how to
accomplish what you are requesting (it’s specialty is in extensible
registration) and how to communicate with a container to achieve it’s
goal (for example, when condition a is met, request type a. when
condition b is met, request type b). On top of that, it instructs the
container on how to call back to Siege for each dependency that a container has to resolve for additional instructions on how to perform resolution.

This means that by using Siege you can gain functionality that your
selected container doesn’t natively support. And as Siege’s use cases
grow, ALL containers functionality will grow. A rising tide lifts all
boats. If the strengths of each container were built as registration
expressions into Siege, all containers would gain this
strength. You would would sacrifice nothing, make no trade-offs and not
be required to learn multiple distinct ways to express how you want a
type resolved.

Limiting your choices

One of the design philosophies behind this project is NOT to limit
your choices. It’s to expand them. If Siege doesn’t support something
that a specific container does, use that container with Siege. Do their
specialized registration to configure the container and then give it to
Siege to do whatever additional registration expressions you need to.
With this approach, we avoid any LCD philosophy, we avoid limiting the
your choices as a developer. Alternatively, you can easily extend the
framework to accomplish what you want so you don’t have to change
containers or feel constrained to a specific one. On top of that, we
deliver functionality that you would not have otherwise. And hopefully,
as the framework grows and evolves, you won’t have to learn 5 different
ways of registering and resolving types. You’ll only have to learn one,
and no matter which underlying framework you use, all of them will
support your system fully. But, that’s down the road from where we are
today, which is why I made it an important design decision to be sure
we didn’t rob any underlying IoC of it’s functionality.

Evolution

I’ll be the first to admit, this wasn’t the direction that I was
going when I first started working on this. I wanted to do an 80/20.
But my point of view has evolved over the last month and my efforts
have gone towards supporting the idea that functionality can and will
be introduced to all containers through Siege. Some of the things I’ve
had to say in this post contradict what I’ve said in previous posts
(perhaps I should update them?) But that comes with an evolving point
of view. It’s organic. Things will grow and change. And I want to thank
Chad for challenging me and making me think more in depth about how to
articulate where I’m going and what I’m doing so I could put up a post
like this.

Let each framework specialize and do what it does best. I don’t
expect the existing framework teams to embrace this idea. There will
always be new features introduced to them. There will always be
features in Siege that none of the others will have. That’s the nature
of the beast.

But my goal is to give you more options and to not take any away. I
hope that clears up any confusion around what the intent is here.

Happy coding!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

For anyone wanting to follow The Siege Project, I routinely post updates on twitter (MarcusTheBold). Feel free to follow.

I did some refactoring and clean up. I’ll address the specifics in a moment. First, I’ll list the files for download for anyone interested:

Siege.ServiceLocation library:

Siege.ServiceLocation.zip
Siege.ServiceLocation.Extensions.zip

ASP.NET MVC Integration:

Siege.ServiceLocation.HttpIntegration.zip

IoC Framework Adapters:

Siege.ServiceLocation.AutofacAdapter.zip
Siege.ServiceLocation.NinjectAdapter.zip
Siege.ServiceLocation.StructureMapAdapter.zip
Siege.ServiceLocation.UnityAdapter.zip
Siege.ServiceLocation.WindsorAdapter.zip

Quick Start:

SiegeMVCQuickStart.zip

A few people have asked me about contributing and extending the Siege.ServiceLocation library. My preference is to keep the Siege.ServiceLocation namespace itself as the main engine for enabling a wide variety of syntaxes and not grow the default syntax beyond what comes pre-packaged (the given-when-then syntax). However, I do want the project to grow and expand to meet the needs of anyone that uses it. Therefore, I’ve added a new project to the Siege.ServiceLocation umbrella: Siege.ServiceLocation.Extensions

Users can download this as an optional library that works in conjunction with Siege.ServiceLocation. Contributors can contribute to this library to create new syntax and new use cases to enable users to solve problems. The only restrictions I will put on this is that it should only reference Siege.ServiceLocation and not any particular IoC or external framework. If you want to integrate with a specific IoC, or another specific framework, I do encourage you to do so — only in a seperate project. I want to make sure that people consuming this framework don’t have to add dependencies to frameworks and systems they do not intend to use.

As these particular cases come up we will address them as necessary.

So what changed?

Not a whole lot. There were some assumptions in the system around conditions and how they were evaluated that I changed to defer through an implementation via interface. What that means is that anyone extending the framework can now determine on their own how a conditions should be determined as valid for a particular use case rather than explicitly comparing against context. Additionally, I extended the framework to track the types it has been resolving. Finally, I simplified some interfaces, particularly around supporting new IoC containers. I expect that I will make a few more modifications before releasing a 1.0 version — the execution context is a primary candidate, as right now it is fairly immature in it’s implementation. The other change I anticipate is to enable the IoC to work with other cross-cutting steps during resolution. Specifically, I’ve been working on incorporating AOP support into Siege.ServiceLocation and it’s almost complete, but I’m still pondering how to incorporate it. It may require a slight refactory, it may not. We’ll see.

Once I have made these two changes I expect I’ll do a feature freeze for Siege.ServiceLocation and release it as a 1.0 version.

New Features in Siege.ServiceLocation.Extensions

Included already in this project are two new types of usages: Factory Methods and the ability to resolve dependencies based on the resolution hierarchy. That is to say, you can conditionally specify types to be used when the container has already decided to use other types. As always, you can additionally refer to the unit tests for detailed examples.

Factory Methods:

You can now specify a factory method to be used when constructing an object, both by default or when a condition is met. This works nearly identically to your standard Given-When-Then functionality, except instead of “Then” you use “ConstructWith”, making it a Given-ConstructWith or Given-When-ConstructWith syntax.

Type Resolution based on parent types

I’m not really sure what to call this. The syntax is like this – Given<BaseType>.WhenInjectingInto<ParentType>.Then<ImplementingType>. Basically it works like this: if you have ‘BaseType1′ which has a constructor dependency ‘IDependency’ and is implemented by ‘TypeA’ and ‘TypeB’, you can say “When you decide to resolve as ‘TypeA’, use the ‘DependencyA’ implementation of ‘IDependency’, otherwise use the default (if one is specified).”

By combining this with normal contextual resolution, you can set up rules for your types to be resolved based on arbitrary context and for their dependencies to be resolved either based on arbitrary context as well, or resolved based on which type is currently being resolved, or a combination thereof. It is important to note that when you specify multiple satisfiable criteria for resolution — for example arbitrary context that is satisfied AND resolution based on a type being resolved that is ALSO true, the system will choose the first applicable use case (the first one registered). Additionally, factory method support is compatible with the aforementioned case of resolving dependencies based on the parent’s type. You can tell it to use a factory when the ‘WhenInjectionInto<T>’ scenario is satisfied.

In Closing

The goal with this system was to be able to quickly and easily extend it to support new syntaxes and usages. When I added these new syntaxes, each of them took me roughly 30 minutes from beginning to all tests passing at the end. While I am the author of this system, I expect that the barrier for other users would not be too much higher given a very basic understanding of the interfaces involved. For example, the amount of code to support Factory Methods was maybe all told about 100 lines of code between syntax and implementation while the amount of code to support dependency resolution based on the type its injected into was less than 150 lines.

Until next time, Happy Coding!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Last night I put together adapters for Autofac and Unity. The process turned out to be rather straightforward; I think all told for both it took me about an hour from adding the projects to all tests passing. I may have a final tweak for this project around how adapters work – there is one method that I think doesn’t need to be placed where it is, so I’ll probably move it. After that, I don’t anticipate many (if any) major changes to how it works … I’ll just put out a Siege.ServiceLocation.Extensions project to house more things (an auto-register, factory method support, things like that). It’ll be a good chance to prove out how extensible this really is.

Other than that I did some tweaks to namespaces to bring everything into one common scheme for namespacing. Nothing new beyond those items; I updated all the downloadable items with the latest versions. Here are the links:

Siege.ServiceLocation library:

Siege.ServiceLocation.zip

ASP.NET MVC Integration:

Siege.ServiceLocation.HttpIntegration.zip

IoC Framework Adapters:

Siege.ServiceLocation.AutofacAdapter.zip
Siege.ServiceLocation.NinjectAdapter.zip
Siege.ServiceLocation.StructureMapAdapter.zip
Siege.ServiceLocation.UnityAdapter.zip
Siege.ServiceLocation.WindsorAdapter.zip

Quick Start:

SiegeMVCQuickStart.zip

For convenience the main library is bundled with the HttpIntegration zip as well as each of the Adapter zip files.

Have a Happy Holidays!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

• Introduction
• Siege.ServiceLocation Part 1 – Introduction and General Use
• Siege.ServiceLocation Part 2 – Contextual Registration and Resolution
• Siege.ServiceLocation Part 3 – Extending the container with custom use cases
• Siege.ServiceLocation Part 4 – Integrating Siege.ServiceLocation with ASP.NET MVC
• Siege.ServiceLocation Part 5 – A guide to getting started with Siege.ServiceLocation

The Quick Start

I’ve put together a quickstart project. You can look through the files in this project to see how everything is put together. You can get the quick start project here:

http://cloud.github.com/downloads/MarcusTheBold/Siege/SiegeMVCQuickStart.zip

Things to look at in this project:

• Global.asax.cs – uses SiegeHttpApplication and shows how to hook up your ServiceLocatorAdapter (the quickstart uses Ninject) and shows where to configure the SiegeContainer.
• ServiceLocatorExtensions.cs – shows how to do registrations with the SiegeContainer, both default and contextual. Also, shows how to do context on a variety of conditions, and shows how to register pre-configured instances with the UserFinder class.
• AccountController – contrived, but shows an example of to work with IContextStore
• The other controllers/services – basic classes that build up how the app works together

This is a purely contrived app that doesn’t really do anything. There are 4 users – Webmaster, AdminUser, TrialUser and PaidUser. For all accounts, the password is pass123. As you login as different users you should see things start happening contextually based on attributes associated with the particular user you are associated with. The different views have text explaining how they work and what to expect.

Hopefully this will give a concrete example of how things work together. As always, if you have questions, feel free to leave a comment and I will respond.

Happy coding!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

• Introduction
• Siege.ServiceLocation Part 1 – Introduction and General Use
• Siege.ServiceLocation Part 2 – Contextual Registration and Resolution
• Siege.ServiceLocation Part 3 – Extending the container with custom use cases
• Siege.ServiceLocation Part 4 – Integrating Siege.ServiceLocation with ASP.NET MVC
• Siege.ServiceLocation Part 5 – A guide to getting started with Siege.ServiceLocation

Get the library used to integrate with ASP.NET MVC by downloading the binaries here: http://cloud.github.com/downloads/MarcusTheBold/Siege/Siege.ServiceLocation.HttpIntegration.zip
Alternatively, you can get the source code here: http://github.com/MarcusTheBold/Siege

Combining Siege.ServiceLocation and ASP.NET MVC

By combining Siege.ServiceLocation with ASP.NET MVC, everything starts to come together. You get more than just the ability to abstract away your dependency on an individual IoC framework (and thereby allowing you to change implementations at the drop of a hat), you get the ability to react to changing conditions in your application and the individual user sessions. When resolving controllers, you have the ability to use views linked to either the contextually resolved controller, or linked to the base type that was requested. Integrating these two frameworks, it turns out, is incredibly simple to do.

SiegeHttpApplication

SiegeHttpApplication is the main component that enables you to integrate with ASP.NET MVC. Inherit your Global application in the Global.asax.cs file from this class in order to turn your regular ASP.NET MVC application into a Siege enabled application. This abstract class forces you to implement only a handful of methods and offers you the ability to override several others (not actual implementation).

public abstract class SiegeHttpApplication : HttpApplication

{

    public IContextualServiceLocator ServiceLocator;

    protected abstract IServiceLocatorAdapter GetServiceLocatorAdapter();

    public virtual void RegisterRoutes(RouteCollection routes) { }

    protected virtual IContextStore GetContextStore()

    {

    }

    protected virtual void OnApplicationStarted()

    {

    }

    protected virtual void OnApplicationStopped()

    {

    }

    protected virtual void OnApplicationError(Exception exception)

    {

    }

}

The only method you must implement is GetServiceLocatorAdapter(). This instructs the SiegeHttpApplication what underlying IoC framework you wish to use. Other than this method, you have the ability to override the default IContextStore used by the SiegeContainer (by default the HttpSessionStore is used). OnApplicationStarted, OnApplicationStopped and OnApplicationError give you extension points to provide additional logic by which you can add custom logic for your own application.

HttpSessionStore

By default, SiegeHttpApplication uses an implementation of IContextStore with the SiegeContainer called HttpSessionStore. This class stores items on the session of the user navigating your website, allowing you to control resolution on a user-by-user basis over the life of the user session. Developers can change this to any other implementation of IContextStore – GlobalContextStore to make your entire application change implementations based on context (for responding to global conditions) or to a custom implementation, if you need finer control over how context is stored and used in the resolution process.

And that’s it!

That’s all it takes to use Siege.ServiceLocation with ASP.NET MVC. I have put together a quick start application that shows in detail how all these parts work together.

Happy Coding!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.