Name:
Location: Rowland Heights, California, United States

Friday, September 23, 2005

To Control or not to Control... that is the question!!!

I'm currently workin with a team of C# Developers where I'm acting as a technical lead - along with another individual that is very savvy when it comes to C# and OOP.
We've taken the Model View Controller approach in developing this new application we're working on these days. We question how much liability we should put on the controllers object when performing CRUD operations. We'd like to take it on a case-by-case basis but to be absolutely sure about this I wanted to post to see what the majority is practicing these days.

Take for example:

A controller object for the customer object may be responsible for calling stored procedures for inserting, selecting, updating and deleting.

But lets take another example:

Would I create a controller object for each Order and OrderDetail? Taking this even further, would every object be responsible for its own CRUD operations? Or would it make sense to allow a single controller object to manipulate for both Order and OrderDetail since the relation is pretty obvious? Or another option would be to allow each controller object to controller its own CRUD where it makes sense?

Your responses are greatly appreciated!!!

1 Comments:

Blogger Robbie Coleman said...

Vic,

How about leaving all CRUD implementation to Adapter objects that share a basic interface that your Business objects call through (via the interface).

example of the Adapter interface could be:

bool Create(IVicsBusinessObjectInterface objectToCreate);
IVicsBusinessObjectInterface Read(string key);
bool Update(IVicsBusinessObjectInterface objectToUpdate);
bool Delete(IVicsBusinessObjectInterface objectToDelete);

Of course Robert would have a better response to the "Model View Controller" implementation since he created it here for us.

;-}
-- Robbie

8:24 AM  

Post a Comment

<< Home