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