Question

I have a structure like this

WebUI project – controllers, views
Framework project- repositories,service layer and domain

So now I have 3 methods/classes

1. Open Id/Open auth

At first I thought I would put all my logic in a service layer in my framework project(preparing the request, checking the response and etc would be in this layer).

So now I am using the dotnetopenauth library and because I need to use the AsActionResult method in my controller(I return “OutgoingWebResponse” from my service layer as I don’t want anything MVC in my service layers)

It got me to thinking when I decided not to have anything MVC in my service layer. As what I read is that your service layer that contains your business logic should not have any dependencies like MVC references because if you go to a windows phone application you should not be using MVC stuff.

Your business layer should be sort of plug and play into any application.

So now I am not sure if I should move what I wrote for openId into my models folder in my mvc projectjust for the reasons above. Since if I do go to a windows phone application or forms application I won’t be using dotnetopenauth since I don’t think it’s supported in these types of applications.

1. My second one is with forms authentication. Again pretty much same reasons as above. Should this go as well in my models folder as a local service/repo layer(ie in the same project file).

2. I am using nhibernate, fluent nhiberate and ninject. My repos are all in my framework project. So I have of course all the references in there. But since I am using ninject for ioc I have all the references in my webui project as well.

I have no clue if this one could be changed to get rid of these references from my webui. I am thinking no because they I can’t have my ioc in my webui where I think it should go.

Answer 1

As a general rule of thumb you shouldn’t write code against requirements that don’t exist ( porting the app to a windows phone ) .

Normally you’d abstract this out in your service layer however OAuth or Facebook integration poses a problem because of its reliance on http and being able to visit the authenticating site.

The problem you’ll run into because “all abstractions are leaky” is that your service layer will be corrupted somehow by the openauth registration process regardless of where you place it. Details about user registration and login such as what their openid url is will end up in your database. You’re service/repo/db/model/mvc/viewmodel/controllers classes are all going to know what openauth is because of its nature.

The good thing is these browser based authentication strategies can live in a Windows Form, WPF or Silverlight application. You simply open a browser inside the application instead of redirecting natively with MVC.

So what I’d recommend is placing your dotnetopen auth registration code inside of your service layer and actually abstracting out how the redirection and callback process happens.

Something like:

public interface IOpenAuthRedirect
{
      public void Redirect( url )
      public void ParseCallback( url )
}


public class MVCOpenAuthRedirect
{
     public void Redirect(url)
     {
        HttpContext.Current.Response.Redirect(url);
     }
}

public class SilverlightOpenAuthRedirect
{
    public void RedirectUrl( url )
    {
        SomeBrowserControl.IForgetTheCallToRedirect( url );
    }   

}

Now the different implementation details are flexible and you can easily transition to another platform besides MVC.