Stupid Question 53: Composite applications and nesting, when do you have to many Russian dolls?
When have you done overdone it with the nesting?
Working on a project using Prism (Composite Application Guidance for WPF and Silverlight) for the first time I had my first introduction to some heavy modular programming. Holy shit is all I can say. You sure got to know where you put your stuff.
Prism works like this, you got a shell,- it’s basically and empty UI structure. Within this shell you define areas, called regions, where you can add modules. The modules are pretty much a natural grouping of functions and consists of one or (most likely) several views. The boostrapper wires up the whole party at startup.
So first the shell. Then module in a region. And the regions can be nested in another region.
Sounds fair enough? Wait. It’s not the last Russian doll.
The Views probably consists of usercontrols, which then again also contain other usercontrols which very likely contain custom controls (this is not unique to Prism or XAML technologies).
Side note:
Usercontrols lets you group together components into a reusable ‘piece of view’ (for example address). Custom controls are what you’ll purchase from Telerik once your realize the limitations of WinRT :P Custom controls are creating your own control based on another one, like a numeric textbox or a WinRT-like FlipView for Silverlight (sure had fun with that today).
You remember those Russian dolls? I’m sure you’ve seen some somewhere. You got a big doll, and inside it another one and then another. And just when you think you’ve peeled the onion right you find another tiny one inside and then one more. At the end you just want to cry. Oh wait, that was the onion.
So what is my question? How many Russian dolls. When and where do you draw the line? What is an appropriate level of nesting of regions, usercontrols and also usage of custom controls (not third party controls)? At what point does it get too fragmented (if there is such a thing) – and what are some signs of that? What should one be aware of?
> What would be overkill?
I promise to start coming up with answers for the questions again, but I haven’t been feeling well (thank you so much for all the ‘get well’s on FB, Twitter and email – you have no idea how happy it makes me to read those! Heartwarming! Truly).
Comments
Last modified on 2012-09-26
Silverlight and PRISM! Good times past. I loved PRISM and the framework it provided. The clean separation of concerns, the decoupling, dependency injection, freedom to use whichever UI design pattern you are most comfortable with (MVC\MVP\MVVM). Best practices! Awesome stuff. But it is a slippery slope and I think it depends on the complexity of the domain, the richness of your UI and the knowledge and experience of the team that has to work on it. All the best OOP practices, S.O.L.I.D principles and coolest design patterns don't really mean anything if other team members don't understand and end up slapping an ugly IF statement around your polymorphic method. Haha. We tried to follow the KISS principle (keep it simple stupid) and not get carried away with the nesting. Modules broken down by business domains 1 Main Shell for the application Shell consists of Regions defining the UI layout Simple composite User Controls \ Views that are injected in and out when needed To me the point where the complexity over takes any gains you achieved from the best practices is when the developer tries to make every single thing reusable by further abstracting and breaking down the user controls / views into more regions with more user controls \ views in an attempt to make everything reusable and sharable. There is a point where common sense should kick in but often doesn't and we end up shooting ourselves in the foot. Great blog keep up the good work!