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
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
to allow you to change how you store data (change db, use xml files etc), by exposing only an interface.
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).