How to architect this ASP.NET n-tier solution?

Question

I have a problem trying to layout my VS solution and I would like some suggestions, please.

Currently, my solution layout looks like the following project:-

Foo.Models
Foo.Repositories
Foo.Services
Foo.Web (an ASP.NET MVC application)

my website (Foo.Web) calls various methods on the Foo.Services namespace. The idea here is that the Services handle all the business logic. The Model namespace are just POCO objects. Repositories namespace is self explanitory.

Constructor Dependency Injection with interfaces handles the black magic of the what layer requires what component.

Problem: I wish to add some Windows Workflow Foundation (WWF) code into the solution, but put this WWF code in the same Foo.Services.dll.

To do this i need to make another project of type Workflow. This workflow has activities, which call the Foo.Services methods. As such, my website now has to call either the services method OR the workflow methods, to do stuff.

I was hoping that the website only ever calls the Services namespace to do stuff.

After all, the service is the main interface between the UI and the business logic, IMO. The fact that I technically use WWF shouldn't be a concern for someone coding in the IUI frontend.

Because the workflow dll calls methods in the Services dll, the Services dll cannot call methods in the Workflow because of circular dependency.

I also can't move all the workflow code INTO the Services dll because the Services dll needs to be some special project type (of type Windows Workflow).

So .. i'm not sure what to do?

How can i make it so that the consumers only reference the Services namespace for business stuff and the fact i impliment this business stuff in WWF is hidden from the consumer?

Do i need to make a WWF project and move all my services code into that, the throw away the old service project? Doing this doesnt' sound very reusable. What happens if i decide to not use WWF for handling certain pipline actions and use something else?

Here's some code to help explain.

HomeController.cs
public ActionResult Index()
{
   // StockService was created using constructor dependency injection.
   var viewData = _stockService.GetStocks(StockType.MostPopular);
   return (viewData)
}

StockService.cs
public class StockService : IStockService
{
    public IEnumerable<Stock> GetStocks(StockType stockType)
    {
        // Dependency Injection defines if the Pipeline is WWF
        // or something else (eg. plain ole functions).
        var stocks = _stockPipeline.GetStocks(stockType);

        // Cache result.

        // Update repostiory. (example of calling the repository)
        _sqlRepostiory.SaveSomeRandomData("Jon Skeet Was Here.");

        return stocks. // Returns a POCO.
    }
}

Thanks peeps.

Answer 1

Have you looked at Rob Connery's MVC Storefront/Kona project? He is doing a very similar thing with WF, and his project is laid out in a somewhat similar way. It might be good guidance for what you are doing. I know that he did work with some Workflow Foundation expert in designing his integration.

Answer 2

A possible solution would be to add an 'Application' layer

Application ---> Services
                    ^
                    |
            \--> Workflow

And call the application layer from the UI. Of course in most cases the application layer would only forward calls to the services or workflow.

Answer 3

FYI- It is possible to modify a non-workflow project to allow the addition of Workflow Classes. Details here.