When I start work on a new web application I tend to reach for the same tried & tested architecture of ASP.NET MVC, BLL (consisting of a set of services that contain all business logic) and a DAL (consisting of a set of repositories that facilitate the unit of work pattern over something like EF/*Linq to SQL*).
The controllers talk only to services, the services only to repositories and other services. At the service layer are where models are defined and these are used as input/output to/from the controllers.
My question is: what are others doing? I'm interested in knowing if people are doing anything different in the context of an ASP.NET MVC web application. For instance, there are concepts like CQRS and Domain Events. Is anyone using these to solve a problem with the method I've described above?
This question is mainly a source of attempting to discover what I don't know I don't know. I hope it's not too vague, but I think it's important to see what others are doing to evaluate your own methods.
We're basically doing what you're doing, except that we consider our repository interfaces to be services (they are defined in the business layer), and therefore our controllers often access them directly. An IoC container takes care of injecting the correct repository implementation via constructor injection. So the data layer depends on the business layer, and is in charge of implementing the repositories, while the business layer just assumes that all the repositories it has defined will be available at runtime.
We've further divided our product up into different modules of functionality. Some of the modules depend on one another (for example, everything depends on our core functionality, and most of the other modules depend on the web portal module), but keeping them in separate dlls helps us to avoid making these modules be too tightly coupled. The system can therefore only load the DLLs for the modules that a given client has paid for. We plan to use an event bus with events defined in the core module to allow the modules to communicate via a publish/subscribe model.
I am using CQRS with MVC. Its nice. You still use the MVC pattern, but in the controller I use the command pattern for the write, and just pure NHibernate Linq for the read... also some SolrNet for the read. :-)
Related
I am currently setting up a simple MVC application that is structured as an Onion Architecture. For simplicity's sake, assume that I have the following projects (disregarding the business and database layers, at the moment):
Sample.Web - This is the ASP.NET MVC Application
Sample.Application - This contains the application services.
Sample.Infrastructure - This contains the infrastructure services.
For now, I am using Ninject (although that will likely change). So, with Ninject MVC, I am registering the Application and Infrastructure services at startup, using the Sample.Web to act as the composition root. Application services from Sample.Application are injected into the controllers, and that is straightforward enough and working well.
Where I am having issues, though, is determining how to properly initialize MassTransit, in the equation. Ideally, I want to have a generic interface to wrap the ConsumeContext instance and allow for me to set up the events. I do not seem to be able to fully set up the instance from within Sample.Infrastructure, as the infrastructure does not/should not know what the events are. I would assume that the consumer classes should exist in Sample.Application, and I do not think that the infrastructure should have a dependency on knowing the consumers.
On startup, System.Web will load the NinjectModule from each System.Application and System.Infrastructure. Does that mean that System.Web should have explicit knowledge of the consumer classes, so that it can configure the IBusControl instance, or is there a more elegant solution?
Right now, the path that I think I am going down is that Sample.Web will load the NinjectModule instances, as it does, and then I will configure the ConsumeContext from Application_Start, after I have explicitly loaded the consumers. However, that would mean that I would have to rebuild/redeploy Sample.Web if I ever add consumers, which is less than ideal and is the root of my concerns. Assuming that consumers are defined within Sample.Application, and all event publications and subscriptions exist within Sample.Application, having to touch either Sample.Web or Sample.Infrastructure to add a consumer is code smell.
Many thanks, in advance.
Edit
As always, after hitting submit, something else comes to mind. I think that one possible solution may be to have Sample.Web as Sample.Application for the known endpoints. Since all events will be published and subscribed from Sample.Application, it would make some sense to have Sample.Web create the actual instance in Sample.Infrastructure and compose the endpoints from what it learns from Sample.Application.
Am definitely open to other solutions, though.
I have an MVC solution setup like this, with three 'projects'.
Web (MVC Project, Views, Controllers, ViewModels)
Models (Domain Objects)
Persistence (nHibernate Mapping, SessionFactory)
I need to begin building the repositories, and was going to start with the Authentication Model. Basically following the default MVC template, have an IMembershipService and an IFormsAuthenticationService and related classes (using custom code, not built in authentication providers).
My question is ...where should this go? My Repositories will need access to both my Domain objects and my Persistence Layer. However I keep reading that any kind of 'coupling' means it is a bad design. So I am hesitant to create a fourth project for the Repositories/Services that references the Models/Persistence ...but I can't really find any other way to do it logically.
This is very subjective.
Do what makes sense to you and your team.
I throw them in with the rest of my Repositories. I mean a User is pretty central to any application right? Does a User own anything? If so then isn't he an root?
Repositories are part of the domain.
Tension will always exist between reducing assembly references and minimizing number of projects. That is, you can make each assembly reference fewer dependencies by breaking up functionality into more fine-grained assemblies; however, excessive division of a project into many assemblies requires more effort to manage.
Another point worth mentioning is that authentication has a couple sides to it. One is managing the model around Users, Roles, Permissions, etc. - this is a domain concern. The other is interfacing with the context of execution (whether this is an ASP.Net app, WinForms, etc.) - this is an infrastructure concern. Consequently, I end up with a small service in my MVC project or WinForms project that performs functions like setting Forms Authentication cookies, or setting the current thread principal, etc.
The Separated interface pattern says that your models and repository interfaces should be in a seperate assembly, apart from the GUI and the actual repository implementation. This is to be able to switch implementations later on and to be able to simplify testing.
I would have no problem with putting the interfaces along with the repository interfaces and the actual implementation in the mvc project or the repository project. It's quite easy to move stuff later on if you use a IoC container.
I've been working with S#arp Architecture but this can probably be applied to any DDD architecture (Domain / Core, Application Services, Infrastructure, and Presentation).
There are many ASP.NET MVC examples that show the controller operating on the domain model through repository interfaces. In fact, the S#arp Architecture tutorial has the StaffMembersController referencing IStaffMemberRepository where it calls FindAllMatching (implemented in the repository). The StaffMember entity, also in the domain/core layer, looks like a data bag with properties and minimal validation on the properties.
Let's say you have a controller that is getting bloated with things that look like business concerns. After reading Microsoft's "Designing Business Entities" chapter in Microsoft's Application Architecture Guide, I believe these concerns could be called "Domain Services".
I want to put these domain services in the domain/core layer but I'm not sure where they should go. Should I create a services folder in the domain/core project that hosts interfaces with an implementations folder underneath it? That seems like a good approach, but I want to see how others have handled this.
Thanks!
What you're calling Domain Services in your question are what I would call Application Services. This kind of confusion over the three different types of service (application, domain and infrastructure) is what lead to the term "Tasks" being used in Who Can Help Me? (instead of application services).
Broadly speaking, I see domain services as actions/behaviours within the domain that don't belong to any single entity - this is pretty much as described in the Evans DDD book. Application services are more of an orchestration layer/facade over the domain that allows an application to interact with the domain without needing to know the full detail about how it works.
So I believe you need an application services layer to remove the bloat from your controllers. This is the approach that's shown in WCHM and it's the one I now follow in my apps.
In terms of where they should live - I'd send to say you should have them in their own project. If you're being purist about it, the contracts should also live in their own assembly, which means that if you like, you can remove all knowledge of the domain from your controllers. However, the WCHM approach places the contracts in the Domain project, and allows the controllers to have knowledge of the entities. Some people complain about this but it's basically just a compromise.
Hope this helps
Jon
Personally, I'm not a fan of how S#arp Architecture (at least, in their demo projects) has the controllers talk directly to the repositories. My $0.02 is that the domain services should be the interface between controllers and repositories. The repositories exist strictly to abstract away the database (e.g., so that you can replace it with, say, LINQ to Objects during testing). The domain services implement your business logic. You want to be able to test those without connecting to a database, or having to mock out your entire session.
An example that I think gets this right is the MVC project developed in Mark Seeman's book, Dependency Injection in .NET.
We built a real world ecommorce platform based on Sharp Architecture and created a demo project that showcases the architecture we put in place. This added the ViewModels, Mappers & a Task layer which helps separate concerns. This is going to form the core architecture of Sharp Architecture v2.0
See http://whocanhelpme.codeplex.com/ for more details.
I'm looking for some feedback on my ASP.NET MVC based CMS application architecture.
Domain Model - depends on nothing but the System classes to define types. For now, mostly anemic.
Repository Layer - abstracted data access, only called by the services layer
Services Layer - performs business logic on domain models. Exposes view models to the controllers.
ViewModelMapper - service that translates back and forth between view models and domain models
Controllers - super thin "traffic cop" style functionality that interacts with the service layer and only talks in terms of view models, never domain models
My domain model is mostly used as data transfer (DTO) objects and has minimal logic at the moment. I'm finding this is nice because it depends on nothing (not even classes in the services layer).
The services layer is a bit tricky... I only want the controllers to have access to viewmodels for ease of GUI programming. However, some of the services need to talk to each other. For example, I have an eventing service that notifies other listener services when content is tagged, when blog posts are created, etc. Currently, the methods that take domain models as inputs or return them are marked internal so they can't be used by the controllers.
Sounds like overkill? Not enough abstraction? I'm mainly doing this as a learning exercise in being strict about architecture, not for an actual product, so please no feedback along the lines of "right depends on what you want to do".
thanks!
Overall, the design looks good to me.
There are a few more items I might do:
Validations - have a 2 step validation -
Step 1 : the domain-level classes enforce their own validity (via attributes or any other mechanism).
Step 2: The repository ensures that the object is valid in the context of the repository
Dependency Injection - use a DI framework to inject dependencies. It will be useful for unit testing. Also, If the service layer where you need to call across services, check if this article on Aggregate Service is useful: http://blog.ploeh.dk/2010/02/02/RefactoringToAggregateServices.aspx
ViewModels - might be tempting to re-use, but wait & watch before you finally decide
HTH.
My opinion is it does and it doesn't.
It does separate logic and data from UI, but it still crams it all together into a single point application.
That's why I think it doesn't really, because Controllers are business logic, Views are UI, Models are DAL. These are now just layers within the same app.
But are layers supposed to be the first or the second variety to be actually called layers?
Anyone wants to add their own 2 cents?
The MVC template project is just to get you started - you can easily move the Controllers and/or Models out to separate projects if you want to, and if it makes sense in your application. Remember, that for a small app with maybe three controllers, a couple of extra classes in the Models layer plus an EF or LINQ data model, you really don't have enough files to justify separation into different projects.
I don't think of Controllers as business logic. They are application logic, the glue which ties together the business logic (Model) and the presentation logic (View).
Well, my birthday cake had layers but it was still one big cake... so yes?
Off course it does!
I think both views and controllers contain user interface logic... the business logic should be in the model (which is not only the DAL).
As the model you could use e.g. CSLA objects and add another couple of physical layers as needed (through configuration).
You have to know there's a difference between logical and physical layers (or layers vs tiers)...
There are a lot of interesting articles on lhotka's site regarding this topic!
E.g. this one and this one.
Layers and tiers are interchangeable. In context of an n-tier you'd call it a presentation tier but in context of a layered application you'd call it a presentation layer. But really they are the same thing.
A litmus test of n-tier application and loose coupling would be if you can take each of the tiers and build them as separate projects and deploy them on different machines.
The key differentiator for n-tier applications is Separation of Concerns (SoC) and low coupling. A truly decoupled application might be one where you have a tier that contains nothing but pure HTML. Then another which contains pure Javascript and uses AJAX to update the DOM and communicate with the web service. The web service comprises it's own set of tiers.
The web service has a routing engine that routes the requests to the different controllers. The controllers sanitize and interpret the request, verify authentication and what not and call the appropriate models. the models in turn must return POCO objects or DTOs and return these to the Javascript which injects them into the DOM. The Javascript may modify the objects and send them back to be persisted into the database. Entity Framework 4.0 has good support for just such n-tier scenarios though it does fall a bit short in the SoC department (strongly types views for example) but it's practical for more purposes.
MVC Futures I believe has support for some Inversion of Control (IoC) containers out of the box and currently if you want loose coupling and truly n-tier scenarios you will probably need to use an IoC container of your choosing.
"Tier" usually refers to different physical servers, while "layers" refers to separation of functionality into loosely coupled areas.
That is, a 3-tier web application:
Tier 1) DB Server
Tier 2) Web Server
Tier 3) Client browser
3-layer web application:
Layer 1) UI
Layer 2) Business Logic
Layer 3) Data Access