views:

399

answers:

3

I will designing a couple of web applications shortly. They will probably be done in asp.net mvc.

In my existing web apps, done in delphi, the data access layer is seperated out into a completely separate application, sometimes running on a different server. This is done more for code reuse than for architectuaral reasons. This won't be a factor in the next app as it will be all new.

Is having a separate data access application overkill in a mvc app? I will already be separating out the business classes by virtue of using MVC, and I will be using an ORM to do the db persistance.

Edit: Just to clarify; I use the term tier to refer to separate physical applications, something more than just a logical separation or layer.

A: 

Great comment Tobias.

I say add enough layers so that it makes sense to you and makes it easier to maintain. Also to keep a seperation of concerns.

griegs
+5  A: 

The term "Tier" in my experience is generally referring to physical application seperations e.g. Client Tier & Server Tier.

MVC - refers to 3 "Layers" with the concern being separation around the 3 concerns it details Model (Data), View (UI), Controller (App Logic).

Now that I have made that distinction regarding my terminology..

Is having a separate data access application overkill in a mvc app?

I would say No(again depending what you mean by application), it is not overkill, as it may in actual fact result in a more maintainable system. Your ORM will possibly allow for new data access options to be plugged in, but what if you wish to add a new ORM? Having a clearly separated Data Access Layer (DAL) will allows for much greater future flexibility in this aspect of your application.

On the other hand, depending on the scale and vision for the application creating a completely stand alone Data Access option may be overkill, but in a nutshell separation of the DAL into different assemblies is very much a recommended practice in the composition of an application implementing the MVC pattern.

Hope this helps, If you need more depth do comment.

StevenH
+2  A: 

Well I gues it depends a little on whether you're talking about tiers (pysical) or layers (logical/projects).

Regarding the layering - you could take a look at something like s#arp architecture (code.google.com/p/sharp-architecture/ ) for an example of how they do it (they have taken a pretty maximal approach to layering).

For an example of more minimalistic views here, take a look at Ayende's blog: ayende.com/Blog/

Regarding tiers - I think needlessly adding extra tiers and putting everthing over the wire will just hit your performance, unless you need to do this for capacity reasons. Get the layers right, and them seperate them into teirs as you need to adjust for capacity (should not take too much refactoring if you've seperated your concerns well).

UpTheCreek