Re: When comes time to save to multiple table handling many relations...

Tech-Archive recommends: Fix windows errors by optimizing your registry

Hi Robbe,

Thank you for your answer.

I just want to detail more to you to know if what I had in mind would
make sense.

Using the MVC design pattern. Here is a case and after, my yesterday's
strategy.

The aspx page is the View, the code behing is the Contol and the logic,
encapsulated in a dll is the Model. For a specific View, the
corresponding Control build a sql query using many inner join. The
Control send the query to the Model. The Model process the query and
return to the Control. The Control can populate the form.

The user fill the form and push the Save button. The Control retrieve
the validated form content and send it to the Model. [According to
your reply, I think I should do that:] The Model then should create all
the insert, update delete query to accomplish the save operation. This
Model fit only for the calling Control. Each Model is specific to its
Control.

This is what I had in mind yesterday:
1)Control layer will build a dataset that contain dataTables and their
dataRelations.
2)This dataset is sent to a generic Model class.
3)Model class will identify parent class and secondly do insert, update
delete from the parent to the children. To do this, the model class
must implement different case of relations such as:
a)one to one from parent to child.
b)one to many form parent to child.
c)many to many from parent to child.
When a programmer would make an application with this Model he should
first know very well his databse. Then he would build the Control
layer according to the database to populate his forms. Keeping the
Model generic and free of Control's specific stuff. The Model would
also manage the open/close connection to the SQLServer layer.

Does that make sense?

Thanks
Marty

.

Quantcast