What are bloating controls?
Can anyone please explain it?
It's a term which can be used to describe a variety of things, e.g. it is commonly used by critics of ASP.NET WebForms where, if you are making heavy use of pre-built WebControls you have little control of the generated HTML, which in many cases appears 'bloated' (large) and 'unclean', 'messy', etc.
I'm not sure 'bloating' is exactly what you mean. Some controls could be called 'bloated'.
In that case it means that some controls offer a great deal of functionality which in most cases is not required. Grid controls tend to be fairly bloated because they expose functionality for sorting, filtering, binding, templating etc.. but it's unlikely that you'll use all of this in a single implementation of the grid so you're taking up much more memory than you actually need which could potentially cause performance issues.
Hope this helps.
I guess people are referring to the fact that some GUI controls are very big and thus a bit hard to understand / use.
Related
This is an issue of code management that I've run into several times. Say I've got a winforms application, and there is a lot of content - hundreds of controls worth of content, most of which have an attached event handler and method. When looking for recommendations on how to separate out such a large file, the 2 big ones that come to mind are regions & partial classes. However, these are both damned by almost every top answer out there.
So I'm wondering, what is the best practice for separating out something like this? It wouldn't make sense to separate them into new classes as they're simply control event handlers. Regions are nice but can still be extremely messy with so much code. I'm kind of at a loss, I can't figure out how to apply the SRP here and any recommendation I see seems to be considered bad practice.
The 'proper' way would be to split the form up into user controls.
Partial classes are meant to separate generated code from user code and regions are just layout (and useless in my opinion, but that is just an opinion)
Splitting the window in user controls promotes proper encapsulation and re-use.
Depending on the project, it might be too expensive to clean it up but splitting out couple of easy ones might help the readability and might save you some time when debugging. Also, when adding new controls and logic, consider adding user controls and start the process of splitting up that way. The cost will then be spread over a longer period and will only be paid for part that you actually use and need to be readable.
I've been reading about FRP lately and really liked the idea so far. There are a couple of things I haven't found much information about, and one of them is this: If I use, for example, a WPF grid for displaying my data (with some thousands of rows), how should I wire the updates to the grid?
I should note that I have relatively little experience with WPF too, but as far as I understand, this would usually be solved by binding the grid to an ObservableCollection<T>, which, if I understand correctly, is very good at handling the updates (meaning updating, adding or removing single items is handled with good performance).
So then, if I wanted to use FRP with immutable collections, this isn't applicable. But what other options are there? If I re-fill the whole grid with each and every update, add or delete, I would guess the performance is quite appalling.
I also don't really have example code to show because, frankly, this is such a basic thing that I wouldn't know where to start without knowing how to do this first. And while I'm specifically talking about C# and WPF in here, I'm also interested in the general principles.
Well, I know there is lots of questions about usercontrol performance, my question is perhaps different.
I would like to generate my webpage dynamically and unfortunately creating a code for that is a pain when the code contains lots of DIVs, IMGs and other controls.
Usercontrols has a advantage becuase they are created by markup code and It's easy to add getters/setters. That means I can easily edit my code and also control the content.
These usercontrols only contain HTML code with few controls like Label or Textbox. That's all.
I would like to ask, if my approach is ok. What's your opinion about that ?
Thank you
Here is a great article describing some pros and cons on using WebForms versus something like MVC. I've used both and like MVC #tonsupontons better.
http://www.codeproject.com/Articles/528117/WebForms-vs-MVC
Your question is somewhat of a religious debate however so I don't think there's a good answer. If it works and isn't bloated full of view state nonsense and you don't do things like Unit Testing then WebForms and UserControls work fine and you should not really notice a performance hit one way or another. <= My opinion I think though, with some exposure to MVC, you might find it much easier to do what you're doing
In Classic ASP, I loved the fact that I could write out variables, formulas, etc., etc. with a simple:
<span class='<%=myClass%>'><%=myariable%></span>
I could format it, or do anything I Wanted. It was easy. I could even run functions on them, etc. I know, in .Net, I can still do all the functions etc., (And the fact that it's treated like an object is good), but I seem to be doing a lot of this, and it's annoying!!!
<asp:Label ID='pnlMyVariable' runat='server'></asp:Panel>
%% CODE BEHIND %%
pnlMyVariable.Text = "Yeah, write this short sentence...";
pnlMyVarialbe.CssClass = "blah";
And don't get me started with the annoying, yet somewhat useful FindControl method!
Is this really the way it is to be? If you say "YES, That's just the way it is", then I will accept it. But surely some people out there (If any are old enough to appreciate Classic ASP) who have seen this to be a little annoying. Am I approaching this correctly?
You're using the asp:Label control correctly, yes. However, it's not a requirement that you use this control. You have lots of other options, but the two which will likely appeal to you the most are:
Use the asp:Literal control. This will work much like a Label but doesn't wrap the value in any additional markup. This allows you to control the markup and styling just like you did "in the old days."
Use the classic syntax. If your page class has a public or protected property on it, that property can be referenced in the markup using the same classic ASP syntax. As a matter of convention in .NET and for a number of good reasons, it's best to use properties instead of directly accessing member variables. But that might end up just being a matter of preference for you.
In webforms, you have this to maintain a model that's similar to winforms. These controls also make use of viewstate, making them hold their values between post backs. MVC is a lot closer to classic asp on the html side, but still very object oriented on the back end. I heavily recommend it!
Are there limits or performance penalties on the amount of code inside of my home.cs form?
I am writing a database application front-end in C# in Visual Studio 2008. The way things are lining up, I am using a tab-page way of changing the info shown to the end users, instead of using new forms.
Coming from VBA/MS Access, I remember that if you go over a certain number of lines of code, it would produce an error and not compile. Will C# do this in Visual Studio 2008, or will I suffer a performance hit? I know code readability could be a problem because everything would be in one place, but I can also see that as an advantage in some situations.
It's not the lines of code in your .cs files that you need to be worried about with regards to performance - it's the number of controls on your form at runtime that might cause problems. If it's just a few controls on a few tabs, you will have no problems. If it's hundreds of controls on lots of tabs, you may have performance problems (not to mention usability problems - I personally hate tab controls with more than one row of tabs).
Also, I don't think tabs are appropriate if the purpose of the UI is more wizard-like where you want the user to interact with all of the tabs in succession. Tabs are meant for presenting sets of options to the user, without requiring them to see all the options at once.
Finally, if the purpose of each tab is significantly different, I find that it's easier to encapsulate each bit of functionality as a separate form. With tabs, you could at least encapsulate each bit as usercontrols, and then have each tab on your form host one instance of a usercontrol.
The only problem i would foresee is that in the future its going to be very hard to maintain.
Try break the logic of that main form up as much as possible into classes so that when you need add something you can actually do it without having a fit.
If you are using tabs, you can still create custom user controls that will hold the content that goes in the tabs. Make a control per tab, and then you can keep your code for the different tabs separate. There is a walk-through on MSDN here.
In response to your comment above, about not showing the tabs, I would really re-think how you're approaching this. Why not simply have all of your user controls sitting on your main form, in a Panel if necessary, have them all set to Dock = DockStyle.Fill, and then change the Visible and Enabled properties based on which one you want to show? You may be making this harder on yourself than it needs to be.
More responses to comments - You may be looking for something like the CardLayout in Java. The source for the GNU Classpath version can be found here, it might give you some ideas on how to implement this.
"I know code readability could be a problem because everything would be in one place, but I can also see that as an advantage in some situations."
In my experience, this attitude will ultimately leave anyone who has to maintain your code in the future with quite a headache, as it's an accepted practice to modularize your code so that the pieces that may change or the ones that serve distinctly different purposes are separated away from each other.
With that said, I don't think there is a limit imposed by VS on the length of your files, but I think you will run into some seriously frustrating performance degradation as your files become longer, especially while switching between design and code views.
I would urge you to save your future self and his/her sanity and break your code up logically into separate files. You'll thank yourself later!
It shouldn't be a problem.
Just keep good coding practices in mind and modularise your code for readability and maintainability.
On the other hand, if you put too many controls on your form, then it will probably take longer to load. Factor that into your design if you want a snappy interface.
Sounds horrible but I don't see any reason why it would be a problem.
I have a form that in inherited with my new job that had over 30,000 Lines. It is completely cancerous. Please think before you code and modularize!