Choose an architecture
We’re almost ready to start coding, but there are a few more decisions you need to make. First up, how will you structure your application’s architecture? (By “architecture” here, I mostly mean your project structure. The physical architecture—whether you’ll be using a server farm or putting the data on the cloud—is very much outside our scope.) Here are some things to think about:
Some platforms imply an architectural pattern. If you’re building in WPF, using MVVM (Model-View-ViewModel) is almost a given, as is MVC (Model-View-Controller) if you’re working with ASP.NET.
A proof of concept is, by definition, throw-away code. You don’t want to spend any more time on it than necessary, and it’s up to you to decide what “necessary” means. Is implementing a pattern like MVVM worth the effort?
The primary goal of our proof of concept is to test the scope and functionality of the application. On the one hand, we don’t want to spend any more time than necessary building it, but on the other hand, we’re probably going to want to tweak the thing to within an inch of its life before we do toss it. The implication of that is it’s worthwhile to build in a certain amount of flexibility. How much?
A good team leader takes the individual skills and preferences of their team members into account. In this situation, you’re both team leader and team. What are you comfortable doing? What are you interested in doing?
What I’d Do
Having chosen WPF for my development platform, there are two primary options: Put everything in a quick-and-dirty single project, or separate the logical layers into separate projects. If I take the second approach, I then have to decide whether to impose the MVVM pattern as well.
I’m comfortable with MVVM, and I know that it makes certain kinds of binding (like handling TreeViews) simpler in WPF (and the things that are more difficult, like messaging, don’t really apply to our proof of concept), so that’s the approach I’d take. Having a very low tolerance for repetitive code, I’d use the MVVMLight toolkit to handle a lot of the basic “stuff”, like wiring up the Views and ViewModels.
On Your Own
We’ve built sample applications that put everything in a single project, and we’ve built samples that used three separate projects. Which will you use?
Will you add another pattern like MVVM or MVC to the overall structure?
Once you’ve decided what you want to do, go do it—Create the solution and add the project(s) you’ll need.