Has anyone successfully implemented a domain model with LLBLGen as the basis of the datamapper?

I have a client with a fairly convoluted schema and we are in the process of deciding whether a domain layer is a feasible way to shield new development from the hard to follow less than intuitive legacy schema. (In the hopes that some day they will be able to clean up the schema to more closely match the domain...may never happen who knows)

Describing the domain is a chore in itself when you don't have much contextual experience but the datamapping will probably prove to be the majority of the work.

Any words of wisdom on how to approach this or horror stories about starting down this path only to abandon it because of the complexity?

Wow, this is the first thread I've ever started on this forum that elicited absolutely no response in this time frame. So does this mean my post isn't clear enough or that nobody has ever tried to map a domain layer to a less than pretty database using the LLBLGen framework to facilitate the mapping from domain object to database?

Fetching projections seems to be a great way to map data onto custom classes but I'm not finding much information on mapping custom classes back into the entities via the resultsetfields created for the projection. Has anyone successfully mapped custom classes back into the table mapped entities in order to persist the data?

In theory is this even close to the approach anyone else would take?

Entities should be the only objects which write to the database. that is the nature of entities. typed/dynamic lists and projections are read-only.

if you want to persist values from the domain to a database there needs to be a corresponding entity to update. so when it comes time to update the database, fetch the entity, set the projected value to the entity then then save the entity.

MyProjection projection = GetProjection();
projection.Process();

MyEntity entity = GetEntity(1);
entity.Value = projection.NewValue;
Save(entity);

If possible just encapsulate the logic into the entity

MyEntity entity = GetEntity(1);
entity.Process();
Save(entity);

Thanks for the reply. The discussion I'm trying to start is about the design of the mapping. What you have said is correct, in order to persist you must use an LLBLGen entity if you wish to use the LLBLGen framework as the "mapper".

In an attempt to make my question more clear:

Domain Object <-> DataMapper <-> LLBLGen Entities* <-> LLBLGen Framework (DQE) <-> Database

• or EntityFields as ResultSetFields by virtue of a projection.

I'm fishing for ideas specific to the use of the LLBLGen framework to facilitate the DataMapper piece. I realiize that the interactions between my Domain Objects are going to be less sophisticated than the interactions with LLBLGen entities.

What I'm really trying to do is provide an API that maps to the business domain so that "developers" will become versed in business process not experts in the convoluted schema design. Sure senior developers will need to maintain the API but production level people shouldn't have to worry about the database issues.

Any philosophers out there want to chime in? I'm also fishing for opinions on whether this is a worthwhile endeavor.

ok, that makes more sense.

I would look into the 2 class entity model. LLBL not only produces the entities with all predefined code. it also produces an empty entity which you can then you to add domain logic. I have only used the adapter model, so I'm not aware of any limitations on SS.

I haven't used this option too much. usually I go with the "original" entity. You're developers will still need to understand predicates and how to use LLBL, but that's the nature of the beast. The same would be true if you use active record or nhiberate.

creating a completely separate process to map the domain to an ORM defeats the purpose of the ORM.

You're developers will still need to understand predicates and how to use LLBL, but that's the nature of the beast.

Only the domain layer (API) developers.

creating a completely separate process to map the domain to an ORM defeats the purpose of the ORM.

In this scenario LLBLGen would be relegated to more of a generated DAL instead of building upon the Lower Level Business Objects that it creates. LLBLGen entities would serve as the transport mechanism to persist the data to the database only. The issue is that the domain isn't modeled well at the relational level. LLBLGen doesn't let you create entities and map the fields to multiple tables (yet) and handle the persistence as seamlessly as it does for the table mapped entities that it creates today. You can create fields on related fields to essentially flatten out an object graph at the "root" object. And who knows this may cover a majority of the disparity between the true domain and the less than optimal relational representation.

But when it comes to common data being stored in multiple locations in the database and other unfriendly data issues I don't think any OR/M tool will handle it out of the box. Essentially we have this scenario.

18 million lines of script operating against a schema thats been hacked to death by almost 20 years of contractors and full time employees. The schema is not going to change enough in a short enough time to facilitate table mapping the entities if we expect the entities to model the business domain. What I'm envisioning is to somehow create an API of Domain Logic maintained by senior level developers so that production level people can construct new applications without the added complexity of internalizing the convoluted schema first.

18 million lines of script operating against a schema thats been hacked to death by almost 20 years of contractors and full time employees.

ouch!

I would recommend NHibernate instead of LLBL for your project. NH provides alot of the functionality you're looking for. LLBL uses the db to model the domain. NH allows the domain and db to be agnostic to one another. using objects at the infrastructure layer like user/collection types and hbm mappings you domain is clear of any persistence logic.

there is an active google group, nhusers, for more information.