Hi
I know you use an editable root object (ERO) for retrieving updating the database. what do people do in this scenario...
A table with many fields 30, 50, >100 say.
One main user screen to do typical CRUD operations using the ERO
But another specific user screen (or process) that needs access to serveral/many of the table's/ERO data items for viewing purposes and in this instance only ever updates one (or two) of the data items.
It seems overkill to call the main ERO data_portal_xyx update stored proc updating 30, 50, >100 fields.
So would I create a second data_portal_xyx and execute a simple stored proc updating that one field or create/use the CommandBase object within BO or what?
Richard
I wouldn't say it was overkill to do the update with just the one DataPortal_Update method and one stored procedure. In fact it's a good idea, generally.
If you start creating lots of different methods calling different stored procedures to update different columns in the table, you have increased your code maintenance effort.
Of course if that's what you want to do its your choice.
Richard B.
I tend to agree. Just that I was challenged by someone who thought updating 130 fields in the table (thru stored proc) when in this instance the user will be only actually updating one field, and so suggested a simple "Update tblX set myfield='xyz' where .....".
Richard
Your first use case is the entire table and the ERO makes total sense.
But the 2nd use case is a subset of various BOs. It should probaly be its own BO and in its DataPortal you would run the "simple" update statement that was suggested to you.
Joe
Hi
So we have serveral use (very similar) cases each fetching and loading a full object but differing only in the data_portal_update method?
So if it's acceptable for the BO to have serveral DataPortal_Fetch overload methods (using different criteria) then why not overload the DataPortal_Update method?
Richard
Richard
If you look at it from a responsibility perspective, you should have one BO responsible for updating all fields and another BO for updating the few specific fields. This seems to be in line with your use cases and two BO will prevent them from being dependent upon one another.
Copyright (c) Marimer LLC