views:

57

answers:

1

I have an asp.net mvc 2.0 application that contains Areas/Modules like calendar, admin, etc... There may be cases where more than one area needs to access the same Repo, so I am not sure where to put the Data Access Layers and Repositories.

First Option: Should I create Data Access Layer files (Linq to SQL in my case) with their accompanying Repositories for each area, so each area only contains the Tables, and Repositories needed by those areas.

The benefit is that everything needed to run that module is one place, so it is more encapsulated (in my mind anyway). The downside is that I may have duplicate queries, because other modules may use the same query.

Second Option Or, would it be better to place the DAL and Repositories outside the Area's and treat them as Global?

The advantage is I won't have any duplicate queries, but I may be loading a lot of unnecessary queries and DAL tables up for certain modules. It is also more work to reuse or modify these modules for future projects (though the chance of reusing them is slim to none :))

Which option makes more sense? If someone has a better way I'd love to hear it.

Thanks!

+2  A: 

I would move them out into their own assembly/class library and create repositories based on "aggregates." Meaning, create a repository and DataContext for all operations that share a purpose (i.e. posts, comments, tags, etc).

This will help separate what each DataContext should be doing and minimize the tracking that the DataContext is doing behind the scenes.

Also, I'm not sure what you mean by, "but I may be loading a lot of unnecessary queries and DAL tables up for certain modules." If you monitor the SQL that Linq is creating you can tune your queries pretty easily. Create public methods in your repositories that only return the appropriate number of records from the appropriate tables. You'll be surprised how efficient you can get the SQL with Linq minimizing "unnecessary queries."

DM
"but I may be loading a lot of unnecessary queries and DAL tables up for certain modules." - by this I meant loading up queries that the model will not need or use.
chobo
Maybe I'm not understanding the situation, but you shouldn't be loading up queries and making database calls that you won't need or use regardless of your choice of application strucuture. For example: the "Admin" area and the "Calendar" area can both work with their own instance of "CalendarRepository" but you should create the necessary public methods so that only the data that is needed gets returned from the database. I guess I'm just finding it hard to imagine a scenario where a lot of unnecessary queries and DAL get loaded...
DM
I was hoping for some more opinions on this, but from my research it seems there are a ton of ways to do things and it seems it comes down to mostly preference.
chobo