Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How do I make a dataset available to multiple forms 2
- Thread starter rambleon
- Start date
JohnYingling
Programmer
Put a function on the first form that returns the dataset.
Private m_DS as Dataset
Public Function GetDataset() as Dataset
Return m_ds
End Function
- free online Compare/Diff of snippets
Private m_DS as Dataset
Public Function GetDataset() as Dataset
Return m_ds
End Function
- free online Compare/Diff of snippets
-
1
- #3
By using the Model-View-Controller design pattern.
In this pattern, the Controller (a separate class) holds onto the data, and the forms (the view part) just access it.
When the data changes, you'd use a delegate and raise an event (OnViewDataChanged or something) that would tell the forms to refresh themselves.
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
In this pattern, the Controller (a separate class) holds onto the data, and the forms (the view part) just access it.
When the data changes, you'd use a delegate and raise an event (OnViewDataChanged or something) that would tell the forms to refresh themselves.
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
JohnYingling
Programmer
I thought the Model held the data. If not, what does it do?
- free online Compare/Diff of snippets
- free online Compare/Diff of snippets
Ooops, I wasn't clear. The model is the data, but the controller has a reference to it.
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
Actually, the controller has a reference to both, since it brokers both access and mutation of the data in the model.
The pattern provides a level of indirection, the controller, between the model and the view, with the goal of thereby making the model and the view more reusable. Application-specific behaviors are as much as possible implemented in the controller.
This is roughly equivalent to the 3-tier model, with model being analogous to data, view to presentation, and controller to business. While the emphasis of the business layer is a bit different (implementing business rules independently of the means of storing and presenting associated data) from that of the controller (brokering interaction between the model and the view) the practical result is more similar, given that the business layer does indeed broker interaction between the data and presenatation layers, and the controller does so in accordance with business rules.
Most of the reusable parts of the MVC pattern are contained in the Model and View, and interactions between them are handled by listeners (i. e. event handlers) in the Controller. However, rather than requiring the Controller to broker data transfers from the Model to the View (which is optional), the pattern makes provisions for direct reference to the Model from the View. This is often more efficient than providing data to the controller and having the controller relay it to the view. Furthermore, mechanisms for gathering and displaying data are typically reusable, as are mechanisms for sending data to a single entry point.
However, the reverse--allowing direct mutation of the model by the view--is not a part of the pattern. Such behavior is not typically reusable, owing to the need for data validation or preprocessing, which work is handled by the controller.
Googling to "MVC Pattern" reveals a good number of articles, although many of them are java-related. Also, this article looks pretty good for .Net implementation of the MVC pattern. If you're a UML fan, this is a good article to read as well.
Bob
The pattern provides a level of indirection, the controller, between the model and the view, with the goal of thereby making the model and the view more reusable. Application-specific behaviors are as much as possible implemented in the controller.
This is roughly equivalent to the 3-tier model, with model being analogous to data, view to presentation, and controller to business. While the emphasis of the business layer is a bit different (implementing business rules independently of the means of storing and presenting associated data) from that of the controller (brokering interaction between the model and the view) the practical result is more similar, given that the business layer does indeed broker interaction between the data and presenatation layers, and the controller does so in accordance with business rules.
Most of the reusable parts of the MVC pattern are contained in the Model and View, and interactions between them are handled by listeners (i. e. event handlers) in the Controller. However, rather than requiring the Controller to broker data transfers from the Model to the View (which is optional), the pattern makes provisions for direct reference to the Model from the View. This is often more efficient than providing data to the controller and having the controller relay it to the view. Furthermore, mechanisms for gathering and displaying data are typically reusable, as are mechanisms for sending data to a single entry point.
However, the reverse--allowing direct mutation of the model by the view--is not a part of the pattern. Such behavior is not typically reusable, owing to the need for data validation or preprocessing, which work is handled by the controller.
Googling to "MVC Pattern" reveals a good number of articles, although many of them are java-related. Also, this article looks pretty good for .Net implementation of the MVC pattern. If you're a UML fan, this is a good article to read as well.
Bob
- Thread starter
- #10
Hmm... still pretty new to .Net, so not sure of best practice, especially with regard to data binding, which seems to have been rehabilitated (most experienced VB6 developers avoid it for the most part). However, can't you just expose what you want as a property of the first form, and access it from the second form? Perhaps someoene else with more .Net experience will weigh in.
Bob
Bob
-
1
- #13
ThatRickGuy
Programmer
Many of us still oppose it, at least in some sence. Binding a GUI directly to the database = bad. Using that stupid arrow control for browsing data = bad. Populating a dataset or custom collection and binding it to a GUI = ok. Generating proper flow/search functionality so users don't have to click the 'next' arrow 200 times to find one piece of data = good.
Also, check the FAQ section, specificly: faq796-5773 which is entitled: a Thousand ways to transfer data between forms
-Rick
VB.Net Forum forum796 forum855 ASP.NET Forum
![[monkey]](/data/assets/smilies/monkey.gif "[monkey] [monkey]")
I believe in killer coding ninja monkeys.
earthandfire
Programmer
RicK, where are the 994 you promised?
ThatRickGuy
Programmer
I'm kinda slow 
I actually have a few more ideas, including some interesting design patterns that I just learned about.
-Rick
VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.
I actually have a few more ideas, including some interesting design patterns that I just learned about.-Rick
VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.I don't have any real insights, other than to just do it.
The hardest part is explaining to people why they need to go to the effort of moving most of their code out of the form, especially if they're used to databinding -- they just don't see the benefit. Which I can understand -- it's a lot of work.
The benefit is (of course), that it makes writing things like Wizards much easier, abstracts the UI away from the operations & data, and allows you to have multiple views of the same data open at once, and they all get updated when the data changes (like a grid in one form and a graph in another, both of the same data). You do need some infrastructure to support this, and you typically add some events/delegates to your entity and collection classes that get raised when something changes (OnDataChanged, etc), so that interested Views know to repaint themselves.
Martin Fowler has come up with a variation on MVC he's calling MVP, for Model-View-Presenter. This is an extreme case of MVC, where the View hands off all the user interface events (mouse clicks, kepresses, etc) to the Presenter class. I'm not entirely convinced of the benefits for general use, but it would certainly be useful in some cases.
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
ThatRickGuy
Programmer
I recently went through the pros and cons of this with my team lead. In situations where you are going to have the exact same process exposed by two identical yet non-compatible interfaces, it can be a good idea.
Say for instance you have an application that needs a windows interface, a web interface, and a PocketPC interface(Pocket PC is stretching it because of CF limitations). You can move all of the controling code, down to interaction behavior into a process class. That process class kicks out the specific entities needed for the event.
So if you have a list box (whether web, or windows) that when the user selects an item a datagrid should populate accordingly. If your process class has a PopulateItemGrid(Selection as Object) as dataset function, then both your web and windows forms only have to have code like:
me.grdItems.datasource = MyProcess.PopulateItemGrid(me.listbox.selecteditem)
I use this style a lot when working with my portal app, it allows me to abstract a bit of stuff, so I can use generic code on the form and let the process class do the work.
-Rick
VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.- Status
Similar threads
- Locked
- Question
