ASP.Net MVC with web service as model?

Question

Does anyone have advice or tips on using a web service as the model in an ASP.Net MVC application? I haven't seen anyone writing about doing this. I'd like to build an MVC app, but not tie it to using a specific database, nor limit the database to the single MVC app. I feel a web service (RESTful, most likely ADO.Net Data Services) is the way to go.

Choric

Answer 1

Edit 2010-11-27; clarified my thoughts, which was really needed.

A web service exposes functionality across different types of applications, not for abstraction in one single application, most often. You are probably thinking more of a way of encapsulating commands and reads in a way that doesn't interfere with your controller/view programming.

Use a service from a service bus if you're after the decoupling and do an async pattern in your async pages. You can see Rhino.ServiceBus, nServiceBus and MassTransit for .Net native implementations and RabbitMQ for something different http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/.

Edit: I've had some time to try rabbit out in a way that pushed messages to my service which in turn pushed updates to the book keeping app. RabbitMQ is a message broker, aka a MOM (message oriented middle-ware) and you could use it to send messages to your application server.

You can also simply provide service interfaces. Read Eric Evan's Domain Driven Design for a more detailed description.

REST-ful service interfaces deal a lot with data, and more specifically with addressable resources. It can greatly simplify your programming model and allows great control over output through the HTTP protocol. WCF's upcoming programming model uses true rest as defined in the original thesis, where each document should to some extent provide URIs for continued navigation. Have a look at this. (In my first version of this post, I lamented REST for being 'slow', whatever that means) REST-based APIs are also pretty much what CouchDB and Riak uses.

ADO.Net is rather crap (!) [N+1 problems with lazy collection because of code-to-implementation, data-access leakage - you always need your db context where your query code is etc] in comparison to for example LightSpeed (commercial) or NHibernate. Spring.Net also allows you to wrap service interfaces in their contain with a web service facade, but (without having browsed it for a while) I think it's a bit too xmly in its configuration.

Edit 1: With ADO.Net here I mean the default "best practice" with DataSets, DataAdapter and iterating lots of rows from a DataReader; it breeds rather ugly and hard-to-debug code. The N+1 stuff, yes, that is about the entity framework.

(Edit 2: EntityFramework doesn't impress me either!)

Edit 1: Create your domain layer in a separate assembly [aka. Core] and provide all domain and application services there, then import this assembly from your specific MVC application. Wrap data access in some DAO/Repository, through an interface in your core assembly, which your Data assembly then references and implements. Wire up interface and implementation with IoC. You can even program something for dynamic service discovery with the above mentioned service buses, to solve for the interfaces. WCF uses interfaces like this and so do most of the above service busses; you can provide a subcomponentresolver in your IoC container to do this automatically.

Edit 2: A great combo for the above would be CQRS+EventSourcing+ReactiveExtensions. Your write-model would take commands, your domain model would decide whether to accept them, it would push events to the reactive-extensions pipeline, perhaps also over RabbitMQ, which your read-model would consume.

Update 2010-01-02 (edit 1)

The jest of my idea has been codified by something called MindTouch Dream. They have made a screencast where they treat almost all parts of a web application as a (web)-service, which also is exposed with REST.

They have created a highly parallel framework using co-routines to handle this, including their own elastic thread pool.

To all the nay-sayers in this question, in ur face :p! Listen to this screen-cast, especially at 12 minutes.

The actual framework is here.

If you are into this sort of programming, have a look at how monads work and their implementations in C#. You can also read up on CoRoutines.

Happy new year!

Update 2010-11-27 (edit 2)

It turned out CoRoutines got productized with the task parallel library from Microsoft. Your Task now implement the same features, as it implements IAsyncResult. Caliburn is a cool framework that uses them.

Reactive Extensions took the monad comprehensions to the next level of asynchronocity.

The ALT.Net world seems to be moving in the direction I talked about when I wrote this answer the first time, albeit with new types of architectures I knew little of.

Rattle

You are comparing ADO.Net to ORM (paragraph #4)? Did you mean LINQ2SQL or EF? – Internationale

Well, ORM uses ADO.Net; I was comparing using them each as the main interface to the database, in which case it makes sense. – Rattle

N+1 on ado.net? I mean seriously.... Lazy-loaded collections only cause N+1 in certain scenarios that you will reach with nhibernate. That's why you have per-query eager loading through fetch strategies in any reasonable ORM out there, including linq2sql. As it happens, nhibernate is actually running ado.net underneath for your db connection... – Dyanne

Not sure what messaging and ESBs have to do with the OP's question. Isn't he essentially asking for something like ADO.NET Data Services (Astoria) - or something similar but not quite as "exposed"? – Wolframite

"As it happens, nhibernate is actually running ado.net underneath for your db connection", that's why I said "ORM uses ADO.Net". What I aimed at was EF which has problems with N+1 and can be said to go under the banner of ADO.Net, just take the first result from google: en.wikipedia.org/wiki/ADO.NET#Entity_Framework. Serialseb: that's exactly what I'm talking about, that if you're willing to step out of comfort zone no. 1 with typed data-sets and EF and that BS, you'll be better off with an ORM. – Rattle

"messaging and ESBs have to do with the OP's question" - he is talking about using WSes as Model in MS MVC (model view controller), which means he'd be talking over http 1.1 for each query against the data model, which would mean that for every request you'd generate another one, over the network, without static compilation of the project (since it's just a proxy being generated) and all the problems that come along with that. (I could expand on this if you wish). When he says: "but not tie it to using a specific database" - I can't see how you can recommend ADO.Net data services! – Rattle

I don't get why this was downgraded. Sure, he confused EF for ADO .NET, but with all the other comments, it's clear he's not clueless on this stuff. All of these comments are constructive in one way or another; I see no reason for the downvotes. – Module

+1 I think it's nice to answer the original question - no doubt the poster has given this some thought before asking, and even though there are valid arguments against using web services to achieve decoupling from a specific database engine, I think it's appropriate to give some pointers at how you could do it if you wanted to. – Jillion

Answer 2

How likely, or useful, is it for your MVC app to be decoupled from your database? How often have you seen, in your application lifetime, a change from SQL Server to Oracle? From the last 10 years of projects I've delivered, it's never happened.

Architectures are like onions, they have layers of abstractions above things they depend on. And if you're going to use an RDBMS for storage, that's at the core of your architecture. Abstracting yourself from the DB so you can swap it around is very much a fallacy.

Now you can decouple your database access from your domain, and the repository pattern is one of the ways to do that. Most mature solutions use an ORM these days, so you may want to have a look at NHibernate if you want a mature technology, or ActiveRecord / linq2sql for a simpler active record pattern on top of your data.

Now that you have your data strategy in place, you have a domain of some sort. When you expose data to your client, you can choose to do so through an MVC pattern, where you'll usually send DTOs generated from your domain for rendering, or you can decide to leverage an architecture style like REST to provide more loosely coupled systems, by providing links and custom representations.

You go from tight coupling to looser coupling as you go towards the external layers of your solution.

If your question however was to build an MVC app on top of a REST architecture or web services, and use that as a model... Why bother? If you're going to have a domain model, why not reuse it in your system and your services where it makes sense?

Generating a UI from an MVC app and generating documents needed for a RESTful architecture are two completely different contexts, basing one on top of each other is just going to cause much more pain than needed. And you're sacrificing performance.

Depends on your exact scenario, but remote XML-based service as the model in MVC, from experience, not a good idea, it's probably over-engineering and disregarding the need for a domain to start with.

Dyanne

Increasingly, enterprise applications are required to be able to use a database from any vendor, and your software should be able to do that. A lot of companies have licenses for Oracle for example, but are now leaning towards MySql. – Terrel

Requiring switching databases is an expensive abstraction to impose, and an expensive switch to make. It's one of those astronaut architecture requirements that, when the switch occur, still cost as much. For most scenarios, one is much better off architecting to one database. Should the requirement for a switch happen, it'll cost anyway, and I'll argue it may cost much less than designing for database agnostic scenarios. Even using an ORM a la nhibernate, one will still have inconsistencies, incompatibilities, variable sorting, etc. – Dyanne

"How likely, or useful, is it for your MVC app to be decoupled from your database?" - I don't see why every other poster needs to tell the person asking the question that they are wrong unless it fits your self-imposed model of refuting the preconditions of the question (that he puts up) rather than asking the core of the question itself! – Rattle

Henrik, I think it's very healthy to ask the reason for a question, rather than answer blindly. It's the culture of cargo cult development and the lack of thorough questioning of the why that leads to most software development nightmares. When you go to the doctor, you don't ask them which antibiotic you should be taking, you ask them if they can cure your illness. – Dyanne

I think you should open up your eyes to new paradigms of development instead of blindly saying no. I've updated my reply, perhaps more to your liking. – Rattle

I have my eyes quite open on new paradigms. What mindtouch is doing is adapted to their needs, and we can discuss at length their design choices. In this instance it smells of astronaute architecture, as no information provided by the person asking the question implies that there is an actual need for using rest as the model in mvc. – Dyanne

I've updated my post a bit. Of course we can discuss at length their design choices; that's the point of being at this site! – Rattle

We are creating a distributed architecture for our services, we are mixing Message Queues with a SOA architecture for our Business logic. We currently have 6 core business domains (all of them provide web services) and our apps require information from all of them when exposing data to our customers. In this case, ¿what would you reccomend? - yes we want to use MVC. – Longmire

Answer 3

You should define your models in a data access agnostic way, e.g. using Repository pattern. Then you can create concrete implementations backed by specific data access technologies (Web Service, SQL, etc).

Plagio

Answer 4

It really depends on the size of this mvc project. I would say keep the UI and Domain in same running environment if the website is going to be used by a small number of users ( < 5000).

On the other side, if you are planning on a site that is going to be accessed by millions, you have to think distributed and that means you need to build your website in a way that it can scale up/out. That means you might need to use extra servers (Web, application and database).

For this to work nicely, you need to decouple your mvc UI site from the application. The application layer would usually contain your domain model and might be exposed through WCF or a service bus. I would prefer a Service Bus because it is more reliable and might use persistent queues like msmq.

I hope this helps

Augean