.NET: Abstracting away the datasource and datacontext

Question

I'm trying to write reusable components for my most common dev scenarios:

I have made a general purpose presentation-layer to present domain-objects and data-objects (dc-serializable) to be encapsulated in the domain-objects. I also have some kind of domainstate/context where I keep all my domainobject-instances referenced. The idea is that the domain-objects have special collections that get populated from the datasource when they are first accessed, on-demand. It's not exactly "DDD" I think but it seem to work...

Anyway, now I'm stuck on the datacontext and datasource-part. I've been thinking a lot on how to store data and interact with the datasource; xml in zip-files, sql-server, sql-lite-files, entity framework, nhibernate, linqtosql, mongodb etc and I can't decide what to use. It appears I need to abstract away both the datasource and the datacontext and instead decide what to use in each application. The important thing is that I don't embed any hard dependencies on specific frameworks.

Is it realistic to abstract away the datacontext and datasource and still have it work well and easy with all kinds of existing frameworks out there? Am I thinking about this wrong? Is this a dead end?

All I want and need (I think) is my domainstate to be able to query the datacontext for objects matching certain criterias. I'm not sure if it should be able to work with entire object graphs or only individual data-objects, or not even concrete types but some generic objects only, or if they should be cloned for each request or not. I feel very confused when I start thinking about this...

Gahhh

Update:

I see a DataContext/DatabaseContext (for instance EntityFramework) as a module/layer to keep objects cached in memory, execute queries, fetch and store data from/to whatever datasource and return typed objects to the consumer. Is this right?

Whats the difference of the Repository-pattern (DDD) and my DataContext?

Update 2:

Basically, this is my model (good or bad?):

DataSource->DataContext/DataObject->DomainState/DomainObject->Presenter

Answer 1

It appears I need to abstract away both the datasource and the datacontext and instead decide what to use in each application. The important thing is that I don't embed any hard dependencies on specific frameworks

That's the Repository pattern right there.

Whats the difference of the Repository-pattern (DDD) and my DataContext?

The repository is a way to abstract everything related to storage access. It's designed to serve the app needs and it receives/sends back objects known by the rest of the app. The DataContext is an implementation detail of EF which itself is an implementation detail of the repository.

The repository has double purpose

1. to allow you to change how you store data (change db, use xml files etc), by exposing only an interface.

2. It frees you from the 'tiranny' of the db centric approach and let's you focus on the domain. This is very important, because every time you start to design an app with the db schema first, you inevitably try to fit the rest of the app in it and you'll have an anemic domain mimicking the database schema.

DataSource->DataContext/DataObject->DomainState/DomainObject->Presenter

In any app you basically have queries (reads) and updates (writes). In 99%, the Domain applies only to writes as the reads have no business rules (no behaviour), you just have to select the relevant data to display.

So for writes I'd suggest this flow

ViewModel (input)->Domain Processing (Entities, Services etc)-> Domain Repository

You can get from the view model to the domain entity in many ways depending on the app. If the Domain is very simple, you pretty much won't need a domain, the view model will be the domain which in many cases will be the same as the db schema.

For reads

Query Repository -> ViewModel (Presenter)

Of course the controller usually calls the query repository and it might assemble the desired view model from the data recevied from the repo (in simple cases the repo returns exactly the view model).

Answer 2

Perhaps you can post some code example? Its a bit hard to understand exactly what you are trying to do, but i'll try to answer some of your questions, comments.

"The idea is that the domain-objects have special collections that get populated from the datasource when they are first accessed, on-demand. It's not exactly "DDD" I think but it seem to work..."

How does this differ from lazy loading? Why do you need a special type of collection? And how does this correlate to DDD?

Is it realistic to abstract away the datacontext and datasource and still have it work well and easy with all kinds of existing frameworks out there? Am I thinking about this wrong? Is this a dead end?

No its not (this is a dead end). You can easily create a domain model which has no reference to your persistence-technology, but you still have to think about the constraints of your chosen orm mapper, for example EF doesn't support enums, nhibernate do. Besides, what do you gain from generalizing this? You never switch mapper once you have chosen one, and even if you do, you should have little problems switching it if the rest of your solution is good (don't scatter your ISession/DbContext/whatever around, etc).

"Whats the difference of the Repository-pattern (DDD) and my DataContext?"

If you mean for example EF DbContext when you say "my DataContext" the difference is that DbContext is a representation of a specific persistence technology, while repository is an technology agnostic persistence abstraction. Its a representation of something which holds your entities, but it shouldn't expose the technology used to make it happen (xml, database, file storage, in-memory, whatever).

As a general note I would not do this my self. Generalizations are difficult and almost always a vaste of time. Developers love generalizations and the idea of "code-reuse", but they seldom introduce more than code-obfuscation and complexity into a solution. Aim for creating something that works and generalize once you start to repeat yourself. Don't try to create this up-front as you will almost certainly end up with something thats useless (or close to). Besides, I don't see what you bring to the table; orm mappers today are non-intrusive and simple to use. You also mention a generic presentation layer, there's nothing more specific than presentation so I don't see the benefits from this either (but maybe if you post some code or explain a bit more).