O/R Mapping tool like Apple has.....for .NET?!?!

[gicio]

Hi!

I post this text 1 year ago. But no one really could give
me an answer. This is the text that I posted long time ago:


I have a fundamental question about
The way .NET handles the object orientated way of
Persistence. I am coming from JAVA and WebObjects (Apple)
World and I am looking for a convenient way of working
with objects without seeing any SQL statements only
objects. I have used that approach for years on the
WebObjects Platform (Enterprise Object Framework) and in
Java recently (Container Managed Persistence). I am
looking for something like that in the Microsoft world.

As far as I understand Microsoft does not distinguish
between the Object Model and the Relational Model. The
main difference is that the Object model allows n : m
relationships and the Relational does not allow them. Here
a small example to visualize the problem:

Example:
There is a Patient object with following Attributes

String patientGUID;
String name;
Int age;
Hashtable diseases; (or some other Container like
Collection or Array)


And there is a Disease Object

String diseaseGUID;
String name;


In the object Model there is relation between Patient and
Disease where the patient has his diseases but on the
other site one disease can belong to 1..* patients. (n :
m)

That n : m relationship can not exist within a relational
database without a link table that contains the
connections between the tables: Patient and Disease.

Now, I would like to connect the object Model containing
TWO Entities (Patient, Disease) with the relational
database (containing THREE tables). Then I want to work
with my objects; e.g. create new diseases connect them to
existing patients by putting the diseases into the array
or create new Patients and connect them with already
existing diseases or just change a Patients name. When I
am finished I just want to say SAVECHANGES and the
database is updated accordingly including all link table
entries.

So all I have to care about are my objects and the
relations between them, some invisible layer does all the
dirty work like building SQL, converting the data types
and caching. So if I fetch a Patient with a specified GUID
I do not have to care about fetching his diseases. They
are fetched automatically. If there are too many Diseases
I do not care some kind of algorithm handles that problem
in such a way that if I have to search all of them for
something they are simply there. They are loaded on demand
(lazy evaluation)

Supposing that the disease has a further connection with
some DiseaseType Object/Table and that table has an
attribute/column "Description" I can access it by typing
the following code:

TextField1.Text = currentDisease.type().description()

Please note that to retrieve the description value I did
only fetch the Patient. The diseases and its types were
fetched automatically.

Is something like that possible or am I excepting too much
of the .NET?

-------------------------------------------------------------------




This tool should be a mixture between Microsoft Visio (I mean ORM modelling)
and a good object-to-relational mapping tool.



Is something like that NOW available????


thx!


gicio

 

[Nerseus]

That's a good bit of text and I think I'm hearing two questions.
First, how can you abstract the getting of a patient so that calling something like patient.Get(123) get's Patient 123 AND all of his diseases (and whatever support tables are needed). You also want to know what's available to store that data client side?

One approach is to use a DataSet. It holds the relationship info for you and you could have the 3 tables needed to map to your relational DB model (if that's what you have). If you create your DataSets through the designer you can have Visual Studio build you what's called a Typed DataSet. That is, it builds a full class structure that maps to your DataTables, exposing them as properties. The columns and rows become collections as well. Very handy

The other alternative is to build the classes yourself, including any relationships. You have a number of options on how to build the relationships. The easiest might be to have the Patient class contain a Hashtable of Disease objects (of a Disease class). You could use an ArrayList as well - any kind of collection to associate those diseases to a patient.

For the record, an n:m relationship is normally called a many to many relationship. What you've described with patiens and diseases isn't a many to many, however (at least not what I'd call a many to many). If designed correctly, there shouldn't be a relationship between patients and diseases directly. Instead, you'd have a Patient Table and a PatientDisease table which contains a DiseaseType key. That's just standard relational db structure. It sounds like the diseases in your sample aren't really a "real" datatable, not something that changes very often and isn't really part of a transaction. Rather, it's a lookup table (or standard values table) which contains the Disease code and a description. The "real" data table is the child table off of Patient, maybe a PatientDisease table.

In the past, I've only come across the need for a many to many in a few, rare instances. Right now, for instance, I have a Plate table (a plate that goes on your car), and a Validation Sticker table. They're both "real" tables - neither is a lookup table. We have the need to put stickers on different plates (not at the same time of course ) so we need a link table - the many to many table - which contains nothing but 3 values: the Identity column, the Plate ID and the Validation Sticker ID. (Ok, there are a few more columns in there, but they're not important for this.)

-Ner