It is hard to believe that we’re finally here, but it is episode #5 in the LOB Chronicles and we’re now getting to start development of our new demo application in Visual Studio. For those tuning in late or in need of a refresher, we’ve already covered how our team explores and exposes user needs via UX work, how that translates into navigation paths and application architecture from a UI standpoint, and how the choice of OpenAccess ORM is going to enable us to use both reverse mapping as well as forward mapping over the life of the project, ensuring smooth migration to a final release location. Of course we have been tracking all of this in TeamPulse, the agile project management tool built with the same RadControls for Silverlight that we are going to be utilizing in this demo. Now we are ready to start laying some of the bricks and mortar of our application by putting together the solution and starting to code.
From a Solution Standpoint
One of the first things most developers will look at when first diving into a new solution, especially one prepared by someone else, is the solution structure. This helps to provide hints about how the solution was developed, can hint at patterns being used (diving into specific projects will tell us even more about this!), and otherwise helps to provide some scope into what the solution contains. With that in mind, here is a look at solution explorer for the CRM demo:
A few things stand out immediately for us Silverlight developers (or hopefully do!), but taking a quick tour through the different projects we see yields the following:
- CRM – Core Silverlight project, likely to hold things like the shell and bootstrapper if we are using Prism, represents the foundation that will contain additional modules
- CRM.DataAccess – Where our domain model lives as well as any additional classes that we need to utilize when interacting with the data.
- CRM.Infrastructure – Used to hold shared items that will be utilized across projects in the overall solution, so anything that should be re-usable will exist here.
- CRM.Web – The website project for our Silverlight solution. This is where you would find the domain service, aka what the Silverlight application is calling to access data for the application.
Pretty straightforward, right? That is one huge benefit of utilizing proven patterns in your development, the logical structures for a solution make sense when you see them elsewhere, and quite often you can even predict what type of code you will see in those projects before ever expanding them.
Diving into the CRM Project
While there is still a significant amount of work to be done to make this a functional application, one thing we do have is an overall look and feel at both the navigation model as well as what views will be needed when interacting with the application. This is one of the biggest benefits of the UX and UI work that we previously completed - even if we aren’t ready to code all of our views yet we can start creating lots of placeholders for items that we know we will need. While this will possibly prove intimidating for the junior developer on the project (wait, how many of these views are mine!?!), it helps provide an overall scope of the work required since a senior developer can translate the UX/UI work into these dummy views and then distribute the work out along with the notes we’ve previously taken. From a workflow perspective, this will mean that time can be spent working through the views in a logical and orderly fashion rather than performing lots of Add > New operations as we work for views that will be needed as we come across them. This also means that, for the sake of re-use, we can identify any UI elements that will be common across views so that we can take that in mind when actually creating the control.
Taking another step into Solution Explorer, let’s look at the CRM project specifically and explore some of the foundation work our developers have been doing to jump start this development process:
If you’re a seasoned Silverlight or WPF developer, you can immediately see one architecture decision that we made based on the files Shell.xaml and Bootstrapper.cs – we’re using Prism! The team structure that we have in place benefits greatly from the modularity that you can get from Prism regions, plus as we move forward you’ll see some other uses of that framework in the overall application development. You can also see both Views and ViewModels folders, meaning we’re using the MVVM pattern to further decouple our UI from our business logic. One step further into the Views folder you can see how our views are broken down, with Companies already being split up into the different views that will load into their respective regions.
And just so you know, I’m not hiding any goodies here that our UI folks have worked up. As an example of how stylin’ our placeholders are… here’s a quick look at the work-in-progress Dashboard.xaml view:
I wasn’t lying. :)
This is just the beginning - from here we get to break functionality down into modules, handle data access through the application as well as how we want to display that data, and otherwise turn this pile of concepts into a concrete application. For anyone who has worked on software before (most of you, I would imagine!), you know that the solution that we see today may vary greatly from the one that exists tomorrow (trust me, it's changed already), so as we move forward we'll cover the why's of what we are doing and show how this demo application is evolving from concept to complete with the Telerik portfolio helping us with every step along the way.
P.S.- Excited about Build? Just a little? Stay tuned for an awesome opportunity before the conference!