I have a given page which displays data that while related, is spread
across different tables. I don't want the UI to call ThisBC.Select() ,
ThatBC.Select() , OtherBC.Select( ), etc and then "know" how to map data
from these result sets to its fields. I think that is too much
responsibility for the UI to handle.
Instead, I'd like the UI to use a "helper" class which will do
ThisBC.Select() , ThatBC.Select() , OtherBC.Select( ), then map the
result set into an easy to use object which mimics what should be on
the screen. The helper class would return this object to the UI,
which would then easily map the object's properties to its form
fields. Saving data would be similar, the UI would populate the
object, then give it to the helper, which would know to start a
transaction, persist the data across the three tables, etc.
Would the "helper" class in this case qualify as a controller? Would
MVC or MVP be overkill? Thanks for any thoughts/advice. Adam
across different tables. I don't want the UI to call ThisBC.Select() ,
ThatBC.Select() , OtherBC.Select( ), etc and then "know" how to map data
from these result sets to its fields. I think that is too much
responsibility for the UI to handle.
Instead, I'd like the UI to use a "helper" class which will do
ThisBC.Select() , ThatBC.Select() , OtherBC.Select( ), then map the
result set into an easy to use object which mimics what should be on
the screen. The helper class would return this object to the UI,
which would then easily map the object's properties to its form
fields. Saving data would be similar, the UI would populate the
object, then give it to the helper, which would know to start a
transaction, persist the data across the three tables, etc.
Would the "helper" class in this case qualify as a controller? Would
MVC or MVP be overkill? Thanks for any thoughts/advice. Adam
Comment