0

MVC sets up clear distinction between Model, View and Controller.

For the model, now adays, web frameworks provides ability to map the model directly to database entities (ORM), which, IMHO, end up causing performance issues at runtime due to direct database I/O.

The thing is, if that's really the case, why model ORM is so pupular and every web frameworks want to support it either organically or not.

To a web site has huge amount of traffic, it definitely won't work. But what's the work around? Connect directly to database is definitely not a wise solution here.

tom
  • 14,273
  • 19
  • 65
  • 124

3 Answers3

2

What's your question?

Is it a good idea to use direct db access from webpages?

A: No.

Is it a good idea to use ORM's?

A: Debatable : See How can I design a Java web application without an ORM and without embedded SQL

Is it a good idea to use MVC model?

A: Yes - it has nothing to do with "Direct" database access - it's about separating your application logic from your model and your display. (Put simply).

And the rationale for not putting database logic inside webpages has nothing to do with performance - it's about security/maintainability etc etc. Calling a usp from a webpage is likely to be MORE performant than using an ORM, but it's bad because the performance gain is negligible, and the cons are significant.

As to workaround: if you mean how do you hook up a database to a web application...?

The simplest way is to use something like Entity Frameworks or Linq-Sql with your Model - there are plenty of examples of this in tutorials on the web.

A better method IMO, is to have a separate Services layer (which may be WCF based), and have all the database access inside that, with DTO's transferring the data to your Web Application which has it's own ViewModel.

Community
  • 1
  • 1
BonyT
  • 10,750
  • 5
  • 31
  • 52
0

Mvc is not about orm but about separation of display logics and business logics. There is no reason your exposed model needs to be identical to you database model and many reasons to ensure that the exposed model closely matches what is to be displayed.

The other part of the solution to scale well would be to implement caching in the control and be able to distribute load on sevaral instances.

faester
  • 14,886
  • 5
  • 45
  • 56
0

I think @BonyT has given a good answer, (and I've voted for it :) ), I'd just add that:

"web frameworks provide the ability to map the model directly to database entities (ORM), which, IMHO, ends up causing performance issues at runtime due to direct database I/O"

Even if this is true, using an ORM can solve a lot of problems with a model being easy to update and translate back and forth between a database. Solving a performance hit by buying extra web servers or cloud instances is much cheaper than having to buy extra developers or extra hours in development to solve things other people have already written ORMs to do for you.

Steve Wilkes
  • 7,085
  • 3
  • 29
  • 32
  • the probelm is that the code is tightly coupled with database, ie, it'll be nightmare for website upgrades. and also, as long as you tie up with database directly, no matter how many machine to add, you won't be able to get ride of the foundamental performance problems. what even strange is that, why all this popular web app frameworks still go toward that direction. – tom Jun 30 '11 at 21:06
  • @Tom: Using an ORM results in tight coupling to database?? Quite the opposite in fact? – BonyT Jun 30 '11 at 21:51
  • @tom - as @BonyT implies - one of the main points of using an ORM is to *decouple* your model from the database. On top of mapping, they also offer easy implementations of the [UnitOfWork](http://martinfowler.com/eaaCatalog/unitOfWork.html) pattern which can drag all sorts of persistence-specific code out of your model. When all popular web app frameworks go in a direction that it seems to you is fundamentally flawed, there's a good chance you're not seeing the whole picture. – Steve Wilkes Jul 01 '11 at 08:12