Initial POCO Design 1-Pager

First Thing on the EF Design Blog

Tim Mallalieu's Blog. — Tue, 24 Jun 2008 22:24:27 GMT

We just pushed the first piece of content to the EF Design Blog . This one is a "Feature Design"

re: Initial POCO Design 1-Pager

rogerj — Wed, 25 Jun 2008 02:54:59 GMT

Hi, Tim,

"Note this is the "feature1-Pager" not the "design 1-Pager" but it's title is "Initial POCO Design 1-Pager"

re: Initial POCO Design 1-Pager

Nullable — Wed, 25 Jun 2008 04:13:00 GMT

POCO is easy to understand with base CLR objects, like string FirstName, int Age and DateTime DateOfBirth... but what's your thought behind complex types (more specifically, List<Order> Orders).

Do you plan using the constructor of the generic list to load the enumeration of "Order" objects?

The same question goes for the ObjectContext with tracking "dirty" objects... it's easy with value types, but again, what are your thoughts / plans for custom types?

Thanks,

-Timothy Khouri

re: Initial POCO Design 1-Pager

GregYoung — Wed, 25 Jun 2008 07:44:36 GMT

I will bring up a few points where I see difficulty...

1) Lazy Loading needing a Repository reference (PI) but I reckon you already know this

2) As Nullable brought up Value Objects in the DDD sense especially considering they are generally assumed to be immutable

3) The use of strings ... What happens when an object gets renamed? I would much prefer to see strongly typed prefetch paths

re: Initial POCO Design 1-Pager

colinjack — Wed, 25 Jun 2008 13:41:41 GMT

All the issues Greg has raised are important and I wanted to add one.

As far as possible we should avoid having to add associations in the domain simply to allow EF to behave correctly. So if I wanted Order to know about Customer but not the reverse then this should be supported.

re: Initial POCO Design 1-Pager

timmall — Wed, 25 Jun 2008 15:51:56 GMT

>>> On Associations

Yep - agreed, you should not need to add associations. We are working on this and will share our thoughts on the blog

>>> On Greg's points

Yep - we are chatting with Greg in email. We expect to be able to support members that are not just scalars so Value Objects (our Complex Types) are expected. It is doubtful that in V2 we will be able to fit support for collections of complex types though. So a reference to a value object would exist a collection of value objects likely wont.

Tim M

re: Initial POCO Design 1-Pager

colinjack — Wed, 25 Jun 2008 20:29:53 GMT

@timmall

My view is whether you support, in V2, something like a collection of value objects is not important. Longer term supporting all the complex mappings that NHibernate and the other mature ORMSs have will be important, but for now I think it should be all about creating a product that encourages good design/testing.

re: Initial POCO Design 1-Pager

JimmyBogard — Wed, 25 Jun 2008 21:37:37 GMT

Maybe others have touched on this...

You should think about changing the name of the CustomerID property on Order, it's throwing me off, as it's of type Customer.

Typically, I wouldn't expose Customer.Orders as List<T>. I would Encapsulate Collection, and only expose operations I support, like Customer.AddOrder. I shouldn't have to have public getter/setter pairs for it to work.

At the least, I'll only expose a getter.

re: Initial POCO Design 1-Pager

jeffders — Thu, 26 Jun 2008 04:10:22 GMT

In regards to materializatoin of relationships...

POCO collections are a particularly interesting issue. Ideally we'd like to support many types of collections such as IList<T>, ICollection<T>, List<T>, etc. In these cases, we wouldn't know what the actual concrete collection type is so we'd need to materialize a List<T> and populate that. We could also materialize a type of wrapped collection (like an EntityCollection<T>) that would provide better hooks into relationship change tracking.

Another option is to be able to map methods that help access collections. It would be the entity's responsiblity to create the underlying collection, and the materializer would call the mapped methods (such as "AddToOrders()") rather than requiring the entity to expose the collection as a read-write property.

Jeff Derstadt

Developer

Entity Framework Team

re: Initial POCO Design 1-Pager

jeffders — Thu, 26 Jun 2008 04:15:45 GMT

>> with tracking "dirty" objects... it's easy with value types, but again, what are your thoughts / plans for custom types?

We are working on different strategies to help tracking changes in custom types, complex types, and relationships. You are right that tracking scalar (value) propeties is easier because you can just call Equals, but it gets harder, especially with relationships. One idea we had was to keep a snapshot of relationships in the context prior to a bunch of changes, and then when SaveChanges is called on the ObjectContext we'd do a graph diff to try to sort out what relationships have been added or removed. This has the downside of requiring a larger resource footprint to store the entire original state of relationships, but it would completely remove any change tracking requirement from the entities.

An alternative is to call a specific API to tell the context when things have changed. This could be done outside of the entity. We are also experimenting with events, but we havent' quite found a common event that works in enough cases.

Jeff Derstadt

Developer

Entity Framework Team

re: Initial POCO Design 1-Pager

Nullable — Thu, 26 Jun 2008 04:49:09 GMT

Hey Jeff, thanks for the reply on the change tracking. I completely feel your pain when you mentioned doing "a graph diff to try to sort out what relationships have been added or removed"... right away I cringed at the thought of the footprint, but as you mentioned, this would be a complete solution.

One thing I do know is that I hate the idea of leaving it up to the developer, and I hate even more *assuming* a dirty state. ASP.NET Profiles does this if you make your own complex type for a property - this caused me a lot of pain (that I don't feel like explaining in this tiny box).

Dare I ask this question... but is providing a transparent proxy to the POCO object out of the question? That way you can wrap what is needed? (I feel like just by asking this question someone is going to jump out from behind a tree and smite me).

Thanks,

-Timothy Khouri

re: Initial POCO Design 1-Pager

unbornchikken — Thu, 26 Jun 2008 08:55:18 GMT

"This has the downside of requiring a larger resource footprint to store the entire original state of relationships"

My opinion is that RAM is far more cheaper than our time. And I dont think there will be any ObjectContext ever which is holding thousands and thousands of objects at a time. ;)

re: Initial POCO Design 1-Pager

serega — Thu, 26 Jun 2008 11:14:30 GMT

Why do you need to specify the C-space name "Customers" in this code:

db.AddObject("Customers", customer);

Is it possible to map one O-entity to many C-entities in the scope of a single context? What for?

Usually it is the other way around, in which case the C-type is overhead.

re: Initial POCO Design 1-Pager

colinjack — Thu, 26 Jun 2008 14:06:24 GMT

> POCO collections are a particularly interesting issue.

> Ideally we'd like to support many types of collections

> such as IList<T>, ICollection<T>, List<T>

This would be useful, especially supporting List<T>. Even better if we could use our own collections (for example to add methods/interfaces that we find useful for a particular project).

> rather than requiring the entity to expose the

> collection as a read-write property.

I take it you wouldn't really need to expose the collection, you could write to the field I'd assume?

> dirty checking

Have you discussed this with people on the NHibernate (and other ORM) team because they already have good solutions to these issues.

re: Initial POCO Design 1-Pager

jeffders — Thu, 26 Jun 2008 18:25:34 GMT

Timothy,

Returning proxy entities is not out of the question, but it isn't something we have completely explored. There are defintely advantages, as we could provide several services that would be hidden from the basic entity. How has the experience been with returning proxies for entities and serialization?

Jeff

re: Initial POCO Design 1-Pager

jeffders — Thu, 26 Jun 2008 18:34:30 GMT

Colinjack,

> woudn't really need to expose the collection, you could just write to the field

We could write to the field for scalar properties or for these collections if we knew a concrete type (eg the field wasn't IList<T>). If we couldn't directly see which concrete type to use, we would have to use a default (such as List<T>). In the case of relationships, we could materialize directly to the "AddXYZ()" method(s) that are exposed on your entity. For example, if we are materializing an Order that is part of the "Customers.Orders

" conceptual collection, and we are mapped to the Customers.AddOrder() method, we could just call this to add the Order to the Customer colleciton rather than creating a collection for Orders and setting it as well.

Jeff

re: Initial POCO Design 1-Pager

jeffders — Thu, 26 Jun 2008 18:49:24 GMT

Serega,

The reason that you need to specify the "Customers" string in AddObject is because EF supports multiple EntitySets per type. This means that the Customer CLR type (and conceptual type), can be mapped to multiple backend sets such as "ActiveCustomers" and "ArchivedCustomers". These sets might represent some horizontal partitioning you have done in your store. You can read more about it here:

http://msdn.microsoft.com/en-us/library/bb738537.aspx

Jeff

re: Initial POCO Design 1-Pager

JorgeLeo — Fri, 27 Jun 2008 22:23:37 GMT

To the association annotation on the class topic: I think that is very hard to avoid it. If there is a single relation between to classes, then at list we need a way to annotate its cardinality.

But what I find more problematic is in the case of the scenario of people and meetings. The meeting relates to different people for different reasons (participants vs. coordinator) and different meetings relate to the same people in different manners (participant in one meeting but coordinator of another). Since the idea is to push the abstraction of the model, rather than having a class representation of the database (as a side note, once I was asked “Why use classes and an ORM if you already have typed recordsets?”), I need a way to say in the model: “These two entities relate, and they can be related for different purposes”.

I know that we can create another class that represents the meeting participation between a person and a meeting, and put there the role… then again; we would be bringing the database to the class domain. I would expect that the framework would be able to annotate and resolve into a scheme representation on its own… Persistent Ignorance

Now, the change tracking… It would be much simpler if the C# team would enhance the language with some concepts from AOP…

ADO.NET Entity Framework ja veel midagi

Iga lahendus tekitab uusi probleeme ehk alati võib leida veel ühe bugi. — Tue, 01 Jul 2008 11:49:12 GMT

.Net -i arendajate kommuuni poolt on postitatud väga asjalik "Vote of no confidence" artikkel ADO.NET

Entity Framework v2.0 development underway (and very open!)

Eric and the .NET Framework — Tue, 08 Jul 2008 16:31:32 GMT

The ADO.NET Entity Framework is very strategic to Microsoft - but a) it is a V1.0 technology (although

Look MOM... no XML

Tim Mallalieu's Blog. — Fri, 18 Jul 2008 21:31:25 GMT

We just wrapped up our first iteration of V2. We are shooting to get another iteration in before PDC

re: Initial POCO Design 1-Pager

jdevonshire — Thu, 31 Jul 2008 23:54:47 GMT

Jeff,

You stated:

>> We are working on different strategies to help tracking changes in custom types, complex types, and relationships. You are right that tracking scalar (value) propeties is easier because you can just call Equals, but it gets harder, especially with relationships. One idea we had was to keep a snapshot of relationships in the context prior to a bunch of changes, and then when SaveChanges is called on the ObjectContext we'd do a graph diff to try to sort out what relationships have been added or removed. This has the downside of requiring a larger resource footprint to store the entire original state of relationships, but it would completely remove any change tracking requirement from the entities.

Wouldn't changes be easier to track if System.ValueType supported an OnChange event? The event would also facilitate rippling changes across a computed value graph allowing flexibility in the conceptual model.

Implementing the event in the base Framework shouldn't be too intrusive to merit consideration.

Entity Classes & Architecture Patterns

system.data.objects dev guy — Sun, 10 Aug 2008 11:09:22 GMT

Entity Classes & Architecture Patterns Part of the Entity Framework FAQ . 2. Architecture and Patterns

Entity Classes & Architecture Patterns

system.data.objects dev guy — Sun, 10 Aug 2008 11:12:15 GMT

Entity Classes & Architecture Patterns Part of the Entity Framework FAQ . 2. Architecture and Patterns

Inversion of Control w systemach zbudowanych w oparciu o obiektowy model domeny

Simon says... — Wed, 07 Jan 2009 22:25:59 GMT

Artykuł opisuje propozycję implementacji zasady Inversion of Control (IoC) w systemach OLTP zbudowanych

re: Initial POCO Design 1-Pager

Tarique — Fri, 28 Aug 2009 22:00:24 GMT

Just one question.

"ObjectContext can be used for CUD operations much like the usage patterns supported today:"

Why CUD and why not CRUD ?