Convention vs Configuration

Topics: Web Api
Jan 17, 2012 at 10:25 PM

How does WebApi support convention vs configuration? I am trying to figure out how I can use SM to apply things such as handlers and operations.

Coordinator
Jan 17, 2012 at 10:39 PM

You can plug in operation handlers, formatters and message handlers using an IoC pretty easily. HttpConfiguration / WebApiConfiguration exposes properties which you can provide a lambda expression to. Using that lambda you can then pull from an IoC the needed extension. For example using Castle Windows you could do. 

 

var configuration = new WebApiConfiguration();
configuration.MessageHandlerFactory = () => container.ResolveAll<DelegatingMessageHandler>();

Similarly you can use RequestHandlers / ResponseHandlers to wire up operation handlers etc.

Formatters are scoped to a conf instance, so you can set the collection to directly resolve off of the container.

 

 

Jan 17, 2012 at 10:41 PM
Edited Jan 17, 2012 at 10:46 PM

But there is no context that can be given to the container to do all the resolving so how would it apply the configurations?

Doing the above code, is just configuration, no convention.

Example: FubuMVC gives graphs that give context to what you are running a convention over.

 

    public class AuthenticationConvention : IConfigurationAction
    {
        public void Configure(BehaviorGraph graph)
        {
            graph
                .Actions()
                .Each(call => call.AddBefore(new Wrapper(typeof (AuthenticationBehavior))));
        }
    }
Coordinator
Jan 17, 2012 at 10:52 PM
Edited Jan 17, 2012 at 10:53 PM

Operation Handlers do have the context as the service is passed to the lambdas. Message Handlers do not because they are low level middleware that only work with the request and response directly. At the point where they run there is no notion of a service.

Jan 17, 2012 at 11:35 PM

So are you talking about doing something like this?

ResponseHandlers = (handlers, endpoint, operation) =>
 {
  ObjectFactory.GetInstances<BaseResponseHandler>().Where(x => x.Matches(endpoint, operation)).Each(x => handlers.Add(x));
 };

I'm looking for actual support for convention over configuration, like how Fluent NHibernate has built in conventions and ways to apply conventions, and FubuMVC has the same.

An example is I have a convention that I applied to Fluent NHibernate that says "All classes that inherit from Entity<> are to be considered for mapping to the database". Or "For all entities set the primary key to Id".

So what I would want is a WebApi convention similar to "For every attribute applied to service actions, check to see if a class exists of the attributenameRequestHandler, and then apply it to the request handlers. Do the same for error handlers, etc."

Coordinator
Jan 17, 2012 at 11:47 PM
Aaah, I see what you are really asking for is a fluent API for configuring web api / apply your own conventions. We don't have anything in the box for this currently, though the APIs we have do enable layering something like that on top. I believe Pedro Felix (though I could be mistaken) has a fluent API for doing something along those lines.

Please open a work item so others can vote.

From: digitalpacman [notifications@codeplex.com]
Sent: Tuesday, January 17, 2012 3:35 PM
To: Glenn Block
Subject: Re: Convention vs Configuration [wcf:286481]

From: digitalpacman

So are you talking about doing something like this?

ResponseHandlers = (handlers, endpoint, operation) =>
 {
  ObjectFactory.GetInstances<BaseResponseHandler>().Where(x => x.Matches(endpoint, operation)).Each(x => handlers.Add(x));
 };

I'm looking for actual support for convention over configuration, like how Fluent NHibernate has built in conventions and ways to apply conventions, and FubuMVC has the same.

An example is I have a convention that I applied to Fluent NHibernate that says "All classes that inherit from Entity<> are to be considered for mapping to the database". Or "For all entities set the primary key to Id".

So what I would want is a WebApi convention similar to "For every attribute applied to service actions, check to see if a class exists of the attributenameRequestHandler, and then apply it to the request handlers. Do the same for error handlers, etc."