johnedw johnedw

Niner since 2005


  • ADO.NET Entity Framework: What. How. Why.

    Before I even read about Entity Framework, I was building a class diagram in Visual Studio 2005, that was modeling a specific problem I was having.

    I wanted a very simple way to store configuration in multiple data stores, yet provide the flexibility that if one of my "Configuration" objects changed where it was stored(for example if SQL was down, and it needed to pull from a cached XML store.) (Don't ask me why, I was being a bit philosophical when doing this.) I came up with the conclusion that I needed some standard way to deal with data storage.

    I had all sorts of fun components, everything from you probably guessed, "Mapping Interfaces" to data type conversation mapping to field name mapping, all sorts of wonderful, "What if something changes, how can I not have to recompile myapp.."

    Then I found out about the Entity framework and I thought, yes, I bet Microsoft would eventually decide to go in this kind of direction. It really does simplify the development when your not dealing with specifics.

    That rule there, dealing with something in a simpler more abstract way? So instead of dealing with bits, you deal with bytes, instead of dealing with Bytes you deal with data types, instead of dealing with data types by themselves, you can reference an object type.....

    Humm, something is going on here, I realized that mapping in general is a fundamental feature which can allow the left hand side of the problem to talk to the right hand side, without worrying about how the right side deals with communicating back. This is wonderful for read operations, because it does not require any talk to the right on how it should deal with things.

    However when it comes to modifying something on the right hand side, there needs to be tools for the left hand side, to understand the procedures for which the right side will perform operations, maintaining some expectation on the left hand side for consistency.

    In other words, abstraction tells the left side, less and less about what is going on in the right side, vice versa, this is great for being secretive or being less complex, however it makes it harder and harder to guess what? Optimize the right side.

    This is one of the reasons we look deep into things in real life, at a small scale, with tools that let us look past the abstractions, at some point, I don't know when specifically, you can no longer change the world when you cannot realign the structures which make the abstraction possible.

    However, I will admit that I would not want to have to deal with the specifics of atomic structure of an orange every time I wanted to eat one J


  • ADO.NET Entity Framework: What. How. Why.

    I think this is all interesting, very cool work and I bet a lot of hours were spent developing, BRAVO!

    The thing is though, I am still not sure I agree with what an Entity actual is trying to do. The thing is, I am not sure that we are trying to model real objects in the sense as they are individual real things.

    First of all, we can't help but ask a few questions, for example, are we trying to model one single entity, or are we actually modeling a pattern match result of entities. What I mean by this is: A true entity defenition, would only work for a specific entity. In fact, I argue that we do not actually model entities even in our head, in the sense of real objects.

    Objects go through changes all the time, on a small scale and a on a large scale, this means that even though I look at a pop can as that single pop can, it may not actual have the same structure on all levels, for example it may have a dent on it.

    However, it is still the same can, why? Because my mental pattern matching routines have not determined it is different enough to appear "like something else". However if you throw that pop can in a series of pop cans, I might or might not be able to find it again, however I might have been lucky and noticed the dent, and if there was a reason to find it again, perhaps no other can has a dent, and therefore I have hopefully found my pop can. But you might argue that all pop cans are a specific entity, in the sense that there is nothing we would perform, verb wise, on that pop can any differently. However this may not be true, I may want to perform an action on a specific can, only based upon the dent.

    This is a completely arbitrary grouping is what i'm getting at. It seems more and more people want to make everyone feel and believe the same way they do. It would be truelly wonderful if Love, Hate and Fear were entities for which we could minpulate in our souls and other's, and maybe then we could come up with an automated way to gauge it.

    It sounds to me like, the problem is being masked here, are we saying developers cannot create the right joins and statements, or is it just too expensive, and Microsoft dosen't want people to have to think about the possibility that Entity Defenitions may break and the flexability of Joins serve their very valuable purpose in relationship modeling.