On Separation of concerns

I just returned home from a business trip.  I have also been tasked with completing a new application in a short timeframe. The application is basically a scheduling tool for our field staff. It needs to display data from our CRM tool.

I am working on this project with another developer who was not being sent on the trip.   Before I left, he and I sat down and architected the design of the app.  And this is how this post gets it's title - We made sure that the application was designed in such a way as to separate the concerns. Essentially, this application needs to do two things

• Get Data about Field Engineers and their schedules
• Present that data on-screen in a certain way

Our design session revolved around what Objects we needed, how they needed to be displayed, and what services would be needed to retrieve them from the data layer.  We then agreed upon and wrote up some Interfaces together.  From there we divided our tasks.

Since I was going to be out-of-town, I took the presentation layer.  My co-worker took the data layer.  While I was on my trip, I was able to construct an entire presentation layer and test it by creating Mock objects of the interfaces that returned dummy data.  My co-worker has been working on the data layer - implementing the interfaces with concrete classes that read from our CRM.

This is a simple description of what we did.  As I write this, I'm thinking about just how simple and logical it is.  It also amazes me at how powerful this simple strategy is, though.  This should be such a standard practice in development, yet so often it is not.   

I can't wait to check all this code in on Monday and see how they mesh together.