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.
Related
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 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.
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.
I am starting a WPF project, which will be fairly complicated in complexity and will make use of a lot of modern UIs, like outlook bar, grids, tabs, etc... I've looked around in the marketplace and there aren't too many control suites. Some of the available ones are either Beta or CTP. Others don't look too polished. Yet others are pretty nice looking.
At this point, today, should I buy or, bite the bullet and build my own? What are the experiences people are having with 1st generation control suites?
The thing to remember is that WPF is very different from WinForms, you can do amazing things buy just re-skining existing controls, when you are starting your first WPF big project you don't yet understand WPF and you don't know the possibilities and pitfalls of the system.
I suggest you start developing the project without those controls and add them later, that way when you get around to adding those controls you will have a better feel of what controls you need and what controls are a trivial customization of an existing control.
If you need anything that isn't trivial it's better to buy - but only if the component you buy is good, so evaluate carefully.
and read Joel's "In Defense of Not-Invented-Here Syndrome" at http://www.joelonsoftware.com/articles/fog0000000007.html
One of the best things about WPF (and XAML in general) is that it makes customizing the available controls a whole lot easier than it was back in WinForms days. Everything depends on the level of customization that you need. If you just have to tweak the look-and-feel of the standard controls, you can do that using a tool like Expression Blend and you don't need any third-party stuff. If you have a good designer on your team (or if you are one yourself), that shouldn't be a problem. And if what you need is some advanced functionality that isn't provided by the standard controls out-of-the box, I'd still recommend trying to customize the standard controls. It's really amazing to what extent you can change the appearance and behavior of a control in WPF by tweaking things like the ControlTemplate, DataTemplate, etc., and/or by subclassing. Besides - now that is just a personal opinion - depending on third-party custom controls generally sucks...
In general, I program in C# so that I don't have to 'reinvent the wheel' every day. I'd recommend using of the shelf components whenever the features provided justify the price there asking for.
That being said… be careful, WPF has not been around long enough for the components to have matured yet.
One of the questions I'm always asking myself is, "what are we in the business of making?". I ask this especially when I'm about to do something that's time-consuming vs buying a 3rd party solution.
Are you in the business of making 3rd party controls? Or does it make more financial sense to buy a package and save your precious time for other stuff?
I would say to take a look on what it is already in there. In my point of view I am pretty much covered with the available ones, and especially in .NET 4, where the DataGridView, Calendar, and DateTimePicker are included (finally).
But if you want also take a look in the components from a company named Infragistics. They are very powerful, but the documentation of them really sucks!