I just spent over a week thinking and designing the same structure when I found this article!
Disregarding the minor unimportant differences our concepts turned out to be the same.
It means that now I am confident it is the right way forward! Thanks!
Some really impressive work, although, to me, it is not clear what exactly your pattern represents. I think this is because it actually encompasses multiple sub-patterns, and is thus difficult to explain.
I have found "Data Access Patterns" by Clifton Nock to be an excellent reference regarding this style of pattern. If I had to try and match your pattern to one of his, it would be "Active Domain Object". In simple terms, this refers to a type of object that handles its own persistence.
However, it is obvious that "Entity" is far more than that - perhaps too much to be a single pattern.
This is one of the best articles I've read on CodeProject. I'm somewhat biased (in a positive way) because I've done some similar work on a recent project. It is along the lines of the Adaptive Object Framework that was referenced in an earlier message. Its amazing how something you think of as being particularly unique ends up being something others have also pursued in their own independent way.
I have't kept up in the past couple of years, but there have been several object-relational systems built in C++ (STYX used to be one). I have built a system in C++ that incorporates this design pattern. My system has worked out amazingly well (which is what drove me to write the article). The platform I developed is called Intelliframe and is the basis for the entire interactive research division at my current employer.
Unfortunantely, I can't just give away the systems code or even binaries, but I can discuss the ideas and re-implement many of the concepts.
I plan to publish more articles on this subject over the next few months. Right now I have a series of articles I am working on that will ultimately incorporate this pattern, but that is still several weeks away.
I am confused: Do we need an Entity pattern to describe a concept of internal data representation? Or Matt is trying to propose something more then that?
As for the implementation of the Entity claas: while reading this article I was thinking about XML, XSD and DOM. I understand that the answer would be that "XML is just another way to store data and we need storage-independent way to treat data storage, etc." Still, XML DOM implementation gives me a very flexible way to store almost arbitrary data structure, XSD gives me a very reasonable way to describe data format. I doubt you can create something more general then that.
Sorry for the confusion. Internal data representaion is just the basis for everything else. Once you have that structured in the proper way, you open the door to having truly data-driven engines. This pattern tries to lay out just the beginning and a few possibilities.
An implementation of this pattern could use XML, XSD and DOM, but may not. There is no problem with these technologies, but in-and-of themselves, there is no engine for automatically dealing with persistince, validation, etc. Rules can be programmed in XSD, but not really configured or driven based on properties within the entity object itself. Persisting the XML to a database requires programming of some kind, not just setting a property. DOM provides easy access to the logical view of the data, but does not provide access control, change detection, etc. All of this is just the beginning, not the end.
Object-relational mapping is (in my mind) not the end-game either. What I want (and have) is the ability to have a system automatically discover new entity types and deal with them accordinly. Every type should benefit from a common set of functionality that is driven by the properties and configuration of that type, not an external program (ie. XSD). I do not want to write programs for each new type. This makes it possible to lower the bar on who can actually use and benefit from the technology. (How many users can write an XML document or create an XSD?)
Just so you know, this is something I have actually implemented, not just an idea. I have written a system called Intelliframe which incorporates this design pattern (as well as other features).
Thanks for the feedback. I hope I answered your questions, but if not, please reply back.
There are a couple of frameworks on the list that have implemented this pattern. Different designs lead to different variations on the pattern, but there are working implementations none the less.
The article proposes some interesting stuff. In practice, I have found some of the proposed capabilities to be secondary concerns and thus I have not implemented them in my framework. Nonetheless, the suggested designs are pretty darned sound and it's good to see column space devoted to this important topic.
One way to look at this is that you have an ENTITY TYPE named "Car".
The entity type of car is defined something like this:
ENTITY TYPE: Car
PROPERTIES: ------------------- IS_A_MACHINE=YES PERSIST_TO=Some DB string PERSIST_TABLE=tblCars
FIELDS: ------------------- MAKE Possible values (1) Chevy PROPERTIES: OWNED_BY=GM FIRST_PRODUCTION=19?? (2) Ford (3) Honda, etc.} PROPERTIES: PERSIST_TYPE=longint PRESENT_AS=DropDown
MODEL Possible Values Case Where Make=Chevy (1) Lumina (2) Camaro etc., Case Where Make = Ford etc. PROPERTIES: PERSIST_TYPPE=DROPDOWN
Much like C++ classes, entity records are istantiated from this entity type. So, they inherit (not the same as class inheritance), the properties of their entity type, are defined by that type and can then be interacted with as entities or as cars. Depending on the impementation, individual entity records can add properties to their entity type that are specific to that record.
<small><b>Jeroen Prins wrote:</b></small> <i>How do I define a relation with another physical table like "Engine"?</i>
One way to do this is by adding a field to the entity type definition named Engine and have properties which tell the system how to determine available engines based on cases.
Something I did not discuss in the article is the need for an engine to manage entites and deal with issues of dynamic case selection. I plan to write more articles on this subject, but right now I am tied up with one of my other article series.
I'm glad you found it usefull. I have found these techniques to be extremely beneficial when developing applications that are heavily dependent on data which sounds like what you are about to undertake.
I've learned about these concepts because last year I used the pattern for an insurance application. Users can build new products by creating relations between entities, attaching acceptation rules, calculation rules, ...
This pattern makes it possible to create new insurance products much faster ...
Paul Watson wrote: "At the end of the day it is what you produce that counts, not how many doctorates you have on the wall." George Carlin wrote: "Don't sweat the petty things, and don't pet the sweaty things." Jörgen Sigvardsson wrote: If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.