none
Best Practice with Data RRS feed

  • Question

  • I was wondering about best practice.

    In the case of where there are data input controls on a form for use in a table I would like to know what the best practice might be.  In the first case, I might have the data input into a variable or maybe the text property.  In the second case, I might have the control bound directly to a table.

    Anyway, what I would like to know about is what might be the whether the preferred practice would be to input your data to a variable or text property and at the point the user is ready to save then update the table from the variables, or is it better to just bind the controls to the table and then update the table when the user is ready to save? 


    gwboolean

    Saturday, February 2, 2019 8:21 PM

Answers

  • Good question, let's examine these approaches.

    • When working with a DataTable where the operations are to read data then data bind to controls.
    • When working with a DataTable where CRUD operations are to be performed, in this case it depends. If there is one record in a secondary form data binding to the underlying DataTable works well but may be overkill while in some cases simply access non-databound controls is just as effective as binding to the underlying DataTable. If there is a reject on proposed changes when bound .RejectChanges can be called while no data binding setting DialogResult of a form can be used to cancel changes.

    If there are zero plans to move away from Windows forms either or will do but that does not mean a developer should be one for all projects but instead examine what fits best.

    If there is a chance to move away from Windows forms then my suggestion would be to work with classes e.g. for working with a Customer, there would be a Person class that Customer inherits from then if later a Manager type is needed Manager inherits from Person (yes this is a tad off the topic). Going this route means everything is light weight and very flexible while at the same time losing some creature features of working with a DataTable.

    Either way works. Others might come back and say one is better than the other yet as mentioned above "it depends". 

    My preference is to data binding to a container for viewing and removal of data while for edit present data in a edit form were each control is enough to know the data being worked on then using DialogResult (as I always present editable data in a child form) to determine to continue or not, same goes for adding data.

    None of the above considered DataAdapter or TableAdapter components.

    If you like to get deeper into this topic let me know I have time today.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites


    Saturday, February 2, 2019 8:40 PM
    Moderator

All replies

  • Good question, let's examine these approaches.

    • When working with a DataTable where the operations are to read data then data bind to controls.
    • When working with a DataTable where CRUD operations are to be performed, in this case it depends. If there is one record in a secondary form data binding to the underlying DataTable works well but may be overkill while in some cases simply access non-databound controls is just as effective as binding to the underlying DataTable. If there is a reject on proposed changes when bound .RejectChanges can be called while no data binding setting DialogResult of a form can be used to cancel changes.

    If there are zero plans to move away from Windows forms either or will do but that does not mean a developer should be one for all projects but instead examine what fits best.

    If there is a chance to move away from Windows forms then my suggestion would be to work with classes e.g. for working with a Customer, there would be a Person class that Customer inherits from then if later a Manager type is needed Manager inherits from Person (yes this is a tad off the topic). Going this route means everything is light weight and very flexible while at the same time losing some creature features of working with a DataTable.

    Either way works. Others might come back and say one is better than the other yet as mentioned above "it depends". 

    My preference is to data binding to a container for viewing and removal of data while for edit present data in a edit form were each control is enough to know the data being worked on then using DialogResult (as I always present editable data in a child form) to determine to continue or not, same goes for adding data.

    None of the above considered DataAdapter or TableAdapter components.

    If you like to get deeper into this topic let me know I have time today.


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites


    Saturday, February 2, 2019 8:40 PM
    Moderator
  • What is the best practice to enter the USA

    1. As a inhabitant of the USA
    2. As a inhabitant of Russia

    The answer of your question is the same. 

    Best practice is always related to the situation. 

    If it is about web and likewise development, real databinding is impossible. For windows forms and WPF it is easy. 


    Success
    Cor


    Saturday, February 2, 2019 9:03 PM
  • Thanks Karen.  I don't know if I am ready to move into that realm yet.

    gwboolean

    Monday, February 4, 2019 2:26 AM
  • Hi,

    Do you resolve the issue? If you resolve the issue, could you please mark the helpful as answer.

    Best Regards,

    Alex


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Saturday, February 9, 2019 4:45 AM
  • Thanks Karen.  I don't know if I am ready to move into that realm yet.

    gwboolean

    I can understand, perhaps in time.
    Saturday, February 9, 2019 11:46 AM