How would you organize this in asp.net mvc?
I have an asp.net mvc 2.0 application that contains sections / modules like calendar, admin, etc. There may be cases where more than one area needs to access the same repo, so I'm not sure where Access layers and data stores go.
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 repos that are required for those areas.
The advantage is that all it takes to run this module is one place, so it's more encapsulated (in my opinion, one way or another). The downside is that I might have duplicate requests because other modules might be using the same request.
Second option Or, would it be better to place DALs and Stores outside the Region and treat them as Global?
The advantage is that I won't have duplicate queries, but I can load a lot of unnecessary queries and DAL tables for certain modules. It's also a lot of work to reuse or modify these modules for future projects (although the likelihood of reusing them is slim :))
Which option makes more sense? If anyone has a better way I would love to hear it.
Thanks!
a source to share
I would move them into my own assembly / class library and create repositories based on "aggregates". Meaning, create a repository and DataContext for all operations that share a target (like posts, comments, tags, etc.).
This will help decouple what each DataContext needs to do and minimize the tracking that the DataContext does behind the scenes.
Also, I'm not sure what you mean, "but I can load a lot of unnecessary queries and DAL tables for certain modules." If you are in control of the SQL generated by Linq, you can customize your queries easily. Create public methods in your repositories that only return the appropriate number of records from the appropriate tables. You will be surprised how efficiently you can get SQL with Linq to minimize "unnecessary queries".
a source to share