database approach for modular apps

Nov 13, 2008 at 7:14 PM

We’re refactoring a large system in an effort to make it more modular (for sales) and more testable (for our sanity). We have confusion on many fronts, but most of it revolves around the database and data access. For example,<o:p></o:p>

<o:p> </o:p>

* On the .NET side of things, I’ve seen some cool approaches to making extendible applications (e.g., MEF, CAG). However, how does this work on the database side of things? We want to pull our highly-coupled monster app apart into “pluggable” modules. Does this mean that we create a database with only the fundamental core, and then each module adds the tables it needs into a separate schema, possibly joining over to the core tables? What about purge routines? Indexing? The other extreme is to create a database that is a superset. But then the modules become coupled to each other at least in terms of release cycle because they all share the same database.<o:p></o:p>

* Finally, some confusion in the Microsoft jargon. From what I’ve seen, Linq to SQL is less suitable for enterprise apps which require domain entities to vary from the database schema, Linq to SQL has lost the shootout with the Entity Framework / Linq to Entities, and now Linq to SQL has been relegated to maintenance mode (here, here, and here, among others). So why do we still see so much press about “Linq to SQL”? Is “Linq to SQL” being used generically, applying (in terms of the actual implementation) to Linq to Entities?<o:p></o:p>

<o:p> </o:p>

Any help, even if it’s just a link to a good blog, is MUCH appreciated! TIA!<o:p></o:p>

Nov 30, 2008 at 4:12 PM
A bit late responding to this message so sorry... just catching up on links I've been meaning to subscribe to!

Regarding the modularity questions, I have a few posts about how I've found this with the WCSF on my blog; primarily the following two posts...

My view is that in the ideal world database components that belong to a module should adhere to SOA principles; that is they should be independent, with clear boundaries between those entities and the ones in other modules. The problem is this makes it difficult to build a real-world system in modules. I think the difficulty is less to do with deployment (as I'd go with your comments about each module adding tables etc as it needs them), and more to do with the data requirements themselves.

For example, I once had a Contact Management module that held all contacts details. The rest of the system needed to retrieve records from other modules, but display the contact's name adjacent to the other records (e.g. Order 1, for Customer 3). Retrieving a list of orders and then doing a "lookup" on every customer is bad from a performance perspective. In fact, someone has commented on the above posts with very similar issues.

I can't answer the problem off the top of my head, but the way I'd be inclined to see it is defining a "public interface" to the database for each module. This might be with Views, Stored Procedures or something else. Modules can then join to the public interface components relatively safely if they must return data owned by another module. The biggest obstacle to this is potentially performance - joining views to views that join to tables might make the code look nice, but could well mean the SQL isn't optimum.

Sorry to add to the questions rather than answering any :-)