It is hard to believe that we are already moving into the sixth installment in this series. It seems like only yesterday we were musing over UX, utilizing our UX base to craft plans for a better UI, and making data considerations in regards to a model and an ORM. Crazy how time flies and how much work goes into a sample demo application before we even begin development!
In honor of the Build conference next week I wanted to dive into our current codebase (TFS + Get Latest Version is our friend here, the developers don’t know I’m coming!) in order to highlight some of the development best practices taking place in our code already (yes, there is always room for refactoring later!) and why these are important to your development both today and tomorrow. While we don’t have time to discuss every technique being used in this blog post, we will explore three specific things already woven into our development practices – and rest assured, as the series and the demo application both mature we will mix other best practices goodness into future posts.
Modularity – Separation of Concerns
We already know that Prism is being utilized for the overall composition of this solution (with a bit of MEF for extra flavor), so let us see how our solution has grown up over the last week or so to better reflect a modular approach to development:
Those of you who have been with us for a while, or at least since the third episode, probably recognize that we split out modules in a very similar format to the navigation map that we crafted weeks ago. There is a very good reason for this – we did our homework. Considering the path that a user will take through an application to accomplish a task can also help us to figure out where to place certain pieces of functionality. Restated in development terms, we understand what views and code need to exist depending on a particular portion of the application that will be in use, allowing us better encapsulation by segmenting logical groups of code together into modules that will only need to be loaded when requested, reducing the overall load time and memory footprint of our application to benefit both a robust set of features as well as making it quick and easy to use if someone just needs to accomplish a handful of quick tasks. In short form – architecting better software that works better for everyone, regardless of how much or how little they intend to use the application at any given time.
Infrastructure – Write Once
This derives from the modular approach in this specific implementation; however this section applies regardless of whether you are developing a modular Prism application, making heavy use of DI or IoC principles, or really any time you are developing software now that I think about it. While the name and implementation may change, the need for an infrastructure/manager becomes apparent thanks to the growing complexity of software and our favorite bug generation mechanism – human error.
Consider the following… You are working on a software project, perhaps a CRM, and you know that there are about 50 other people working on the same project. Continuous integration is running so you are quickly aware of the fact that a change you just submitted, a quick update to a class, has broken the build (should have run tests before checking-in, tsk tsk!). You look at your code and think that everything is just fine and that your refactoring couldn’t have broken any functionality, then you notice that slightly off color that denotes a string value being used. It all starts to make sense, and after a little debugging you find that the string value, we’ll say it is the name of a region you are injecting a view into, has changed in the view but your code still references the old name.
Now there are obviously a few possible solutions to this issue. First, you can find the new name of the region, carefully copy and paste it from the view to your code (copy and paste makes it fool-proof, right?), then check-in. Presto, it works, problem solved… until the view name changes again due to another developer reading MVP X’s blog and realizing that the naming convention previously used could be done better. A better approach would be to eliminate these so-called “magic strings” and instead utilize a constant that is defined in your infrastructure class so that both the view and your class reference the constant, not a string value in each, allowing changes to take place in one spot and populate out to the rest of the application. Show any seasoned developer the following two lines and they will easily pick out the one less likely to break:
var region =
Using a constant for the value, we’re future-proofing and ensuring that if anything were to go wrong with ContentRegion we can start our investigation with the string that every other piece of code is referencing rather than trying to search for every instance of that magic string.
Universal Concepts, Predictable Results
For anyone that is a fan of Microsoft Patterns and Practices, you might notice the slight play on words that this section header utilizes. This is part of why this post is a pre-Build special. I guarantee (well, as best I can, I don’t have top secret information from within Redmond backing this, just a hunch) that these concepts along with the other universal software development concepts that have been proven time and again (check out the Telerik P&P Evangelist, Phil Japikse, in nearly any talk he gives and you’ll see how this applies) will continue to remain valid. Software you develop today and five years from now will still benefit from separation of concerns, encapsulation, SOLID principles, modularity, using constants instead of magic strings everywhere, so learning and utilizing these concepts today will continue to help into vNext of anything that gets released.
The same applies to User Experience (UX), which is why taking advantage of events like the Billy Hollis (Un)Official Build PreCon is such a huge opportunity. Much like he states on the page, these concepts are universal and will apply to UX for as long as you develop software, so getting yourself educated and immersed in these concepts early is a crucial part of being successful as you mature as a developer and move forward in your career.
Next time around is actually going to be in two weeks - mainly because of what whole Build thing taking place. We'll get to see more of the code and UI that is being developed towards our finished application. Stay tuned!
Evan Hutnick works as a Developer Evangelist for Telerik specializing in Silverlight and WPF in addition to being a Microsoft MVP for Silverlight. After years as a development enthusiast in .Net technologies, he has been able to excel in XAML development helping to provide samples and expertise in these cutting edge technologies. You can find him on Twitter @EvanHutnick.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.