what are the best ways to manage code in a single-form app that has many different components? for example, think of a financial app that has a product picker for browsing/choosing a product to view; a handful of real-time tickers for prices, interest rates, or whatever; a scrolling news feed; various charts; a grid displaying locally calculated values; etc.
would you create a custom control for each distinct component, even if they're not going to be used outside of this app? or could you do it with classes that implement the logic for each component and somehow update that actual control in the gui? two components may need to interact with each other, e.g. you click a cell in a grid, and it brings up some chart (would the main form handle sending the message?)
I have a habit of letting form code get bloated as features are added and I really want to get familiar with a better way. I'm working with c# (not using WPF) but I guess basic design principles aren't necessarily language-specific.
You can try the MVP pattern.
See - Gui Architectures by Martin Fowler
It somewhat depends on how large the application scale is, and also the lifetime of the application.
In nearly any reasonably sized application, I'd recommend separating individual sections into separate UserComponents. That being said, there are many ways to move beyond that, including using plugins/DI, etc.
I'd recommend reading (or at least skimming) the Composite Client Application Guidance for ideas. The message passing questions as well as the questions on different approaches to tie together individual components are discussed in detail.
There are many gems that would be relevant in the Composite Client Appilcation Guidance, even though you're not using WPF or Silverlight. Many of the sections in the guidance are not technology specific - they relate more to how to bring together multiple pieces, promote reusability and flexibility in the design, etc. These apply no matter what technology you are using.
I tend to do everything as a custom control and them use panels for my placement. I then create a new instance of the control and add it to the panel.
This allows for me to do custom constructors, which I have been finding more useful as I am trying to use a DI/IOC framework on my current project.
Related
I'm looking for best practices for sophisticated UI logic implementation. I'm working on a Windows Forms application, but I believe there should be generic patterns for solving this problem on any platform.
I have a number of controls on my form, there are lists, buttons, tables and a tree view. So, the idea is that depending on "context" some of the controls are enabled, while others are disabled. Some of them can provide some features for the moment and others don't.
Currently it's implemented "as is". I handle events, check for changes (new tree node selected, couple of nodes selected, etc.) and then decide whether some of the controls need to be disabled or enabled. I don't really like this approach because the Form code looks to complicated. And if I need to add more logic, it becomes even more complicated. I'm really concerned, since we're quite agile and new features or lots of changes are the daily norm.
I'm thining of separating all this logic into parts (Features), where each feature is an object that know how to check its state, and depending on this state, enable or disable the related controls.
Don't really want to invent anything new and trying to find any good ideas that are widely used. Please, don't recommend single UpdateUI() method approach, I believe that won't change anything in the long term.
Thanks.
This blog series may be what you are looking for:
http://codebetter.com/jeremymiller/2007/07/26/the-build-your-own-cab-series-table-of-contents/
(may look like a lot of material, but start just with the "Humble Dialog box", based on Michael Feathers great article). This is all about "how to separate your logic from your UI code", which may solve most of your problems.
User interface data binding and encapsulating your business logic into business objects is the way to go. CSLA.NET framework by Rocky Lhotka has a lot of great features built-in as well as a number of sample applications. I've used it in a medium-size WPF project and a huge WinForms/CAB application and really enjoyed it.
In general, I am wondering when to use custom controls vs integrating the control directly into your form.
In particular, I have a form that contains a tab page, with 6 tabs each containing a number of .net framework controls. Currently, I have in my project 6 user defined controls that I dock onto each of those tab pages.
I.e. there is no reuse of controls, I just use them to manage the complexity of a form that would otherwise contain 10 gridviews, 20 buttons, 6 date controls, etcetera. Would you consider this a good way to manage this complexity, or would other alternatives be better (in enabling the programmer to
understand what is going)?
I think this kind of division of page to custom/usercontrols may prove to be useful even without reusing the parts. This gives you:
Encapsulation - you can hide the boring plumbing and fragile internal state from higher level code, leaving you a much cleaner set of controls to work with and more business-oriented code on page level.
Separation of concerns - you can make pieces which are simple, yet logically whole.
Readiness for reuse - may never become useful but it does make you feel more powerful ;)
But be aware that this can backfire if your components are not properly named and grouped, badly designed, you use lots of dynamic loading, do not provide good API or nesting goes too deep. I have seen it happen in a legacy app and it wasn't helpful that way.
If done well, worth it. With inexperienced/sloppy team members, better don't.
What is complexity for you? If you ask me, you are making it more complex if you use usercontrols as the way you use. Usercontrols should be used to prevent code duplication. Basically what you are doing is moving your logic to your usercontrol and deviding your logic into multiple pages so you have less code on your main page. This shouldn't be your main concern if you ask me.
If you have complex logic in a view model or controller for the sections of screen, then this can be a beneficial approach. It is making your overall form more of a composite. You can develop the functionality behind the sections/controls in the view models and/or controllers separately and unit test them separately. As ImreP says, this is along the lines of separation of concerns.
However, if there's a lot of interaction between the separate controls on your form, then this might not be the right way. If you can find separate areas of behaviour/responsibility for different areas of the form, then the split may be a good idea, given your premise that there is quite a lot of UI happening.
If it's simply for the sake of having fewer basic controls in each package, and there's no chance of reuse of any of the components, then it might be muddying the waters somewhat.
A good test might be to show it to someone else on your team and see how long it takes to explain it to them. You'll get a good idea if it's intuitive or not by trying to show it to someone who hasn't come across it yet.
I have never used MVC before and would like some advice.
I have actually already written quite a bit of code, but looking at it, it seems to be quite highly coupled between classes and there is a lot of code written on the actual main form of the winform. I am a University student, recently started on a 12 month placement, so do not have much real world experience.
My system is effectively a WinForm GUI that has, amongst other things, a treeview that is popualted at load via an event. And then when the user clicks on a node, it gets a datagridview from a dllplugin (which obtains the data from an Oracle DB via a perl script.
My question, is would MVC apply in this circumstance, and would anybody have any good advice/resources on how I can now, post-design to implement it?
Thanks.
The MVP pattern is more adapted to WinForms applications. Here's a nice article you may take a look at.
Received wisdom is that MVC is good for the web but has some constraints when operating in a desktop environment (I'm not sufficiently experienced in applying this sort of pattern in either context to make a worthwhile judgement).
The pattern that Microsoft (for one) are pushing for forms use is MVVM - which is Model View View Model - and it provides a similar set of benefits in terms of separation and testability. Even allowing that I could wish I knew more I can see what and why, especially if you're looking at WPF (and Silverlight) but in any context where you're trying to ensure separation.
The MVC pattern can work well with WinForms, see this question.
There are lot of related pattern to choose from; in the case of WinForms (unlike WPF) there is no clear winner.
Partly this is due to everyone having different aims, do you care most about:
Code reuse between Forms in the UI
Being able to support form the one UI system
Easy unit testing
Etc
I have been hearing a lot of hype about MVVM for WPF. When do we use it? Is it a use for everything or does it only have specific uses? Is it worth it for every project?
It can be useful in any project, but I find it particularly helpful in situations where providing a clear separation between business logic, interaction logic, and user interface is required (large applications or applications involving multiple developers/designers).
Model = Business Logic
Contains the model of whatever business process/object I am working with.
ViewModel = Interaction Logic
All the code that controls how the model is accessed and modified (e.g. edit/undo functionality, lazy loading, etc.)
View = User Interface
The interface (defined in XAML) that the user interacts with. I try to minimize the use of code-behind in this layer, pushing that into Attached Properties or the ViewModel.
There are doubtless many other uses for MVVM, but this particular scenario is the one I have found to be the most useful in my own WPF development experience.
I've found it useful even in relatively small projects, if I'm making a lot of use of databinding and an object data model / models.
In terms of WPF and Silverlight?
In theory for everything - every non-trivial project (and possibly even then). Its part of a wider process (it creates separation of concerns and allows for testing and other nice things). Basically if you're going to do it (and I think you probably want to, I certainly intend to with new projects) then you should do it pretty much across the board.
If you haven't already, go watch the video linked from here: http://blog.lab49.com/archives/2650 - I found it very helpful in getting my ideas straight.
Better to ask: when shouldn't you use it? The most obvious example is when data binding isn't appropriate and you have to manipulate elements of the view directly in code - if, for instance, your application needs to update the visual state of hundreds or thousands of visual elements in real time you may not be able to afford the overhead of data binding.
Every time I start on a simple project and think "this is so simple, MVVM would be overkill", approximately 8 hours later I get to a point where I realise that using MVVM would make things much simpler.
So I'd say most of the time using MVVM will actually simplify your UI logic, even if you initially think it will be overkill. Projects have a habit of getting more complex over time, and the separation of business logic and view logic enforced by MVVM enables the project to grow in a far more controlled way than having you business and UI logic all mixed in together.
I'm currently working on a large project, where we implement mvvm, CAL (Composite application guidance) in Silverlight. Of course, level of separation of concerns is very high.. but
1) the code gets too robust.
2) MVVM looks great for small projects ( all these hello-world samples all over the internet), but it reduces your oppportunities: For example, Routed events (great instrument) are still EVENTS, but, as you know, it's strictly forbidden to use them directly, as soon as this is code-behind) if you want to follow mvvm.
3) Command Binding STILL doesn work properly in Silverlight(.net4.0, vs2010). It's a long story, just keep that surprise in mind, when your CanExecute delegate will not fire at app start.
A good answer to your question is "MVVM is good for projects with simple UI logic".
Thanks, Ilya.
I can't decide if it is good or bad to make many user controls. I am only doing it cause I find it easier to work on a control where there are not a lot of components. If something needs to be fixed it is also easier. Kind of like how you split your program up in a lot of classes.
However multiple controls adds a bit more complexity when it comes to passing data around. I guess my question is more if it is normal to create a 'god' class when it comes to GUI programming in winforms.
Almost every video tutorials I see, they only work on one form! While I can use like 5 controls before I have a form.
Reasons to create User Controls in WinForms:
Reuse of functionality.
Encapsulation and data hiding.
Readability and maintainability.
Single responsibility principle.
Design-time editor integration for assignable properties.
Ability to refactor/enhance/reuse in the future.
Have you heard about encapsulation and components? It is just your case.
Well from a Web Developers perspective -- no, I don't believe so. In fact I believe in the NerdDinner book for ASP.NET MVC there's a section where the author(s) creates a partial (similar to usercontrol) for the sake of readability purposes. And these are the top guys at MS who wrote this book.