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!
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.”