Wednesday, October 10, 2012

Massive N-Tier Sample App, explained and code from end to end... The sample? A Zombie Incident Explorer...

CodeProject - Zombie Explorer : A N-Tier application front top to bottom

I just want the code man give me the code, well ok chillax, its right here:


I had posted this article earlier this week, but had to take it down to fix something with it, so apologies if you have already seen this.

This article is something I have been meaning to do for some time, not really  for anyone's benefit other than my own really. Before we get onto what the  article will cover, let me just outline why I wanted to write this article.

I have been working with both WCF/WPF a while now (I know some people  consider these old technolgies now, but I can assure you they are both alive and  well, at least in my part of the world), and I have seen a variety of different  approaches to developing a n-teir application with these technologies.

I have seen good and bad things, some of the bad things being:

  • Ridiculous amount of methods on a service, which become quite  unmaintainable quite quickly
  • Everything is its own service, where you have about 30 WCF services all  trying to call each other. Nightmare man
  • Bad seperation of concerns, where the dependency graph is all screwed up,  and your UI inadvertently ends up knowing way to much as it is forced to  reference things it has no business knowing about
  • Use of Reference.cs (more on this later)
  • Lack of support/thought for DD/IOC/Mocking or any of the cool stuff people take  for granted now days

I thought it would be nice to try and see if I could make a demo app which  kind of did things the way I had it mapped out in my mind. I just  wanted to be able to do a complete application from database to WPF client all  the way through, with only my own thoughts (and headaches/nightmares) to deal  with.


For the attached demo code I wanted to make sure I covered the  following aspects

  • Provide good level of seperation of concerns, that is the UI should not  care about server side business logic, why should it.
  • Be able to easily easily swap out/test certains areas of our application  (IOC allows this)
  • Database access should be as lean as possible (NHibernate and  Respository pattern usage facilitate this)
  • Should be able to test a small part of the overall system

I have called the project "WcfExemplar" which I hope people do not find  arrogant, it is certainly not meant to be. It is called that more for  me really, as I was doing this to prove something to myself, so it was an  "Exemplar" for me if you will.  I hope you forgive me this one indulgance.

So what does the demo app do?

It is a WPF (Prism/MVVM based) client which communicates with a Console hosted WCF service  application. The application allows users to search database stored zombie incidents. The  user may also add new zombie incidents. So its actually not that complicated, it  is basic CRUD stuff.

I think the main salient points are as follows:

  • WPF front end (that I will not dwell on too much, as that is a  mere vehicle to illustrate the server side concepts) which allows users to
    • Search for items (I am storing zombie data where a  heading/description and GeoLocation data are stored for each zombie  incident)
    • Add new items
    • View items on a map (I have chosen to use Bing maps)
    • Use Rx to show an RSS feed of global zombie incidents (as a bonus if  you will)
  • It uses a shared DLL where only the relevant things are shared between  client and server, which ensures the dependency graph make sense. So things  like those shown below would typically be shared
    • Business Objects
    • Service contract
    • Fault contracts
  • There is NO auto generated Reference.xx or client proxy, we  use a shared DLL and hand craft our own client proxy
  • It uses Fluent NHibernate for its persistence, where ISession provides the Unit Of Work (UOW)
  • It uses IOC such that any component that talks to an external part (ie  database) can be easily substituted. This is done from the WCF service down
  • It uses business logic to do any work on objects before any attempt to  persist an object is done.
  • It keeps connections to the database at a minimum and only engages the  database for the minimum amount of time.



This is a massive article, by the one and only, Sacha Barber. And you know me and zombies, so... :P

No comments: