I'm wondering if anyone can share their thoughts, experience and guidance on how to approach the data access layer for a composable application?
By composable application, I mean an application with the domain layer made up of modules. The goal is to make the application highly extensible by 'plugging in' additional (or replacement) modules. Each module encapsulates (and isolates) a set of related functionality.
My dilemma is the right approach for the data access layer to support this composability (modularity) while still providing isolation from the back-end database. Because each "module" can implement its own set of domain objects, there really is no way that I see an ORM like EF working unless I simply create one mega data context or make changes to the data access layer each time a new module is introduced (which isn't possible if the module is added by a 3rd-party or as a post-deployment extension).
For what it's worth, this is an enterprise-scale application with a database containing over 200 tables and a ton of sproc, udfs, etc.
What advice can you share?
I confirmed today that we will be using a legacy data store for the solution that utilizes stored procedures and user-defined functions for the majority of the data access operations. Our hope is to evolve away from this as time goes by, but the budget and timeline for the project dictate the we build on top of the existing databases.
Does that change your thoughts?