Decouple Entities and DataContext

[GoogleCodeExporter]

1) I'd like an option to have entities generated in a seperate assembly. 
In this scenario I'd have the entities plus their base class in one
assembly and dbml, data contexts/querries in a sepererate assembly that
references the entity assembly.
2) I'd like to run validation checks/rules on the entities themselves in
addition to having them run by the data context in an update scenario. 
That way I can run data integrity checks on the entities before even
attempting an update.  Maybe I can put this logic into my own custom entity
base class but it would be cool if the functionality was out of the box as
well....

Original issue reported on code.google.com by mich...@bouck.com on 21 Mar 2009 at 6:32

[GoogleCodeExporter]

A picture is worth a thousand words!

Original comment by mich...@bouck.com on 21 Mar 2009 at 6:45

Attachments:

• Issue80.png

[GoogleCodeExporter]

Original comment by shannon....@gmail.com on 23 Mar 2009 at 10:00

• Added labels: PLINQO

[GoogleCodeExporter]

1) Does LINQ to SQL let you do this?

2) You should be able to run these manually by executing something like
   User user = new User();
   context.RuleManager.Run(user);
   However, we have determined that there is an issue with doing this and filed issue
81 as a result.  Adding a Validate and IsValid to EntityBase is a good idea.

Original comment by shannon....@gmail.com on 23 Mar 2009 at 10:23

• Changed state: Accepted

[GoogleCodeExporter]

1) L2S puts the entities/DataContext into the same assembly but that's not the 
point.
 The point is I want a clear separation of concerns: the entities and the code that
persists the entities (i.e. the DAL) are two separate functions.  I don't want 
my UI
code to know anything about the DataContext.  If I manually structure things 
this way
L2S works fine (in disconnected mode without change tracking obviously).
2) I would like the entities themselves to own the validation business rules 
and be
able to run these validation rules on the entities themselves for the same 
reason
listed in 1 (i.e. separation of concerns).  Non data consistency-related 
business
rules should live in the Manager classes which would run these rules in 
addition to
running the entity data validation rules in an update scenario.

Original comment by mich...@bouck.com on 24 Mar 2009 at 1:59

[GoogleCodeExporter]

Original comment by shannon....@gmail.com on 21 Apr 2009 at 3:57

• Added labels: Framework-PLINQO

[GoogleCodeExporter]

Original comment by shannon....@gmail.com on 21 Apr 2009 at 4:18

• Changed title: Decouple Entities and DataContext
• Added labels: Type-Enhancement
• Removed labels: PLINQO

[GoogleCodeExporter]

Issue 87 has been merged into this issue.

Original comment by shannon....@gmail.com on 28 Aug 2009 at 4:38

[GoogleCodeExporter]

I've starred this, but I don't think this will be a small undertaking.
If we really want to decouple things, we'll need to remove all references to 
Linq, ie
all the EntitySet collections.  

This is what I would envision:
DT Objects - simple, data-only classes, very light. ("Core" or Entities 
Assembly)
Entities - including all the good validation stuff, events - heavier ("Core" or
Entities Assembly)
SqlEntities - built off of the entities, which would include all the Linq 
related
dependencies. (Data Assembly)

Original comment by beriniw...@hotmail.com on 15 Sep 2009 at 11:48