Question Too many DataSources in one form not good?

[bullsquad]

Hi,

A simple question. I am new to Data Binding in VB.NET. I want to know if an application would take a performance hit if there are too many data sources associated with a form in VB.NET.

My data comes from 4 different tables so I have created 4 different data sources but not sure if there will be a performance hit.

Thanks in advance

 

[Element6]

The more resources you require the more management is required; so the statement is too broad; yes of course you'll take a performance hit.

It's not uncommon to use multiple data-binders; personally I think that is the lazy way.

If you want an efficent clean approach; use one binder and hot-swap it in code run-time it's more organized; and unless you have data that is semi-permenant it's not going to affect anything.

Personally, I am a quirky developer compared to some, I never like to use more then I need and I will always approach a problem from a more difficult solution then the lazy drag a drop process.

Go back to the basics as a developer is my recommendation

Always dispose of what your not using.
And never create more then what you will use.

 

[jmcilhinney]

It depends exactly what you mean by "data sources". If you mean that you have set the DataSource of four different controls then that's not a problem at all. If you mean you have added four items to the Data Sources window then that is a problem. Four tables in one database is one Data Source.

I disagree with Element6's implication that using drag & drop and wizards is inherently lazy. There's more than one definition of "more than I need". Spending hours or days re-inventing the wheel does noone any good if you could do the same in minutes using tried and tested methods provided by the IDE and then get on with the rest of your app. You should certainly strive for efficiency in your code but saving a few milliseconds here and there is pointless in most GUI-based applications. Data-binding is tried and tested, it works and it saves you time so that you can concentrate on other areas of your project. If data-binding can't do what you need to do, then look at implementing something yourself. Easily maintainable code should be one of your primary aims and if you can use existing Framework functionality rather than writing your own code, that's generally going to be more maintainable, i.e. you don't have to maintain it.

 

[Element6]

On that note I have to agree with jmcilhinney, we have difference of opinions based on implementations but I think he is making a good point here. If the Framework allows for it use.

I have said this before and I will say it again about my own coding style, I don't code to fit the .NET Framework or any other Framework for that matter I am a generalist and I like to hot swap code from one language to another for security reasons which is my primary field of study so for me it makes sense to reinvent the wheel some times to make up for dynamic coding and language swaps.

jmcilhinney makes an excellent point that it's not required, and normally it isn't, but I would say that if you have 100 data bindings or some extreamly large number your probably doing something way too process intensive, and need to reevaluate your approach, maybe shrink down the information on the form of what is needed and the most common problem most developers make is timing functions; not all information needs to be displayed at the same time and some can be "derived" or calculated. That does not mean it cannot be done, it just means that there is probably a more efficent solution and you haven't reduced to the problem down to the least common denominator.

I say as a rule of thumb, more then 3-4 data bindings on a form is probably too many.

 

[PhillD]

What about lookup boxes? This also creates datasets and binding sources. It would be easy to exceed 4 or 5 on that basis alone.

 

[PhillD]

To be honest, I am not a real fan of using the wizards either. But right now, I am very new to VB 2008 and trying it out. I am not a fan of having 4 or 5 objects added to my form just for the purpose of maintaining a dataset to a single table. It gets very messy. I wish they could have accomplished the same functionality in fewer objects. For example, I'm still confused why the functionality of the binding source couldn't be implemented into the dataset. Why does binding source need to be it's own entity?

 

[tinybamboo8x11]

i see it's normal.i often place lots of data sourses in a form but nothing wrong happens

 

[jmcilhinney]

Having lots of data-binding is not an issue per se. Data-binding is simply code in the Framework. If you don't use data-binding then you have to write the equivalent code yourself anyway. A problem might occur if you have too many controls on a form, whether bound or not.

 

[Element6]

It's an issue of "readability" not a problem with Microsoft .NET. Techically I think you can make as many DataBinders as your memory can handle and it should still work and technically that should be infinate because of managed resources.

My comment is more along the lines of design issues; Would you rather sort through code or through the IDE's scrolling "UserControls"; which is better then nothing but hard to view iin my opinion I think I rather that be a listbox like the file system viewer.

As for combo boxes or list boxes I don't think it's easy to exceed 4 or more on a given form, you would REALLY have to try to do that.

The superset I use to measure is based on simple data types like Date/Time
Even if your combo boxed down to a degree of detail of milliseconds and include the date that would be MM / DD / YY / H / M / S / MS 7 layers. I can't think of a solution where you would have more then 7 layers of data, and if you do say you move to N of infinity layers; you can probably cycle the same data binder as a matter of recursion.

Again, in those cases I think it's specific to when you display data to the user; and that is what I refer to as a timing functions. Is it appropriate to show the user information regarding the USA when the user is viewing statistics data relevant to the moon? Maybe, but I highly doubt it.

 

[jmcilhinney]

It's an issue of "readability" not a problem with Microsoft .NET. Techically I think you can make as many DataBinders as your memory can handle and it should still work and technically that should be infinate because of managed resources.

My comment is more along the lines of design issues; Would you rather sort through code or through the IDE's scrolling "UserControls"; which is better then nothing but hard to view iin my opinion I think I rather that be a listbox like the file system viewer.

As for combo boxes or list boxes I don't think it's easy to exceed 4 or more on a given form, you would REALLY have to try to do that.

The superset I use to measure is based on simple data types like Date/Time
Even if your combo boxed down to a degree of detail of milliseconds and include the date that would be MM / DD / YY / H / M / S / MS 7 layers. I can't think of a solution where you would have more then 7 layers of data, and if you do say you move to N of infinity layers; you can probably cycle the same data binder as a matter of recursion.

Again, in those cases I think it's specific to when you display data to the user; and that is what I refer to as a timing functions. Is it appropriate to show the user information regarding the USA when the user is viewing statistics data relevant to the moon? Maybe, but I highly doubt it.

I'm not sure we're talking about the same thing exactly. Generally speaking, each form would only have a single data source, like a DataTable or some more specific list. If that list contains entities that have N items of data associated with them then you'll want N controls on the form bound to them. That's N data bindings. It's quite appropriate for N to be greater than 4 or 5 if the entities being displayed require it.

In some cases you might have two or possibly more lists that are related to each other that you want to display in the one form, but those cases would be in the minority and the number of lists should certainly be kept small, generally for the sake of UI design as much as anything else.

I was taking about the first case, but I get the feeling that you were talking about the second.

 

[Element6]

I was referring to the second.

Either way I still agree.

I have found that some developers usually try to run "simultanious" transactions, but I never do that through the Interface or Application and normally always at the Database level. It seems to junky and way too expensive in resources to me and I never got to the point I could wrap my thoughts around Why I would ever do that.

I think the intended MircroSoft design, and feel free to correct me if I am wrong, is 1 datasource -> bounded to N controls per relative information; in some cases you may spawn 2 or 3 datasources for relational data.

But, I think the Jr. Developers do N DataSources to 1 Bounded control; they think in the inverse and so the problem is a Multiple Selects represented as Multiple DataSources. Each contain seperated datafield values such as "Select [LastName] from TblUser", "Select [FirstName] from TblUser", "Select [Address] from TblUser", etc...

Instead of 1 DataSource "Select [FirstName], [LastName], [Address] From TbleUser" then binding to the appropriate fields.

Has MicroSoft considered putting in a "Design Assistant" which will help developers make their code more efficent? Where it makes code efficentcy recommendations? Is that even possible?