Question

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.

Answer 1

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.