Because Evejob Project developed in few frameworks, we need to make clear “terminology” differences used by different frameworks as well as different strategies to develop MVC applications using such frameworks. Let’s start from MVC frameworks: 1) ASP.NET MVC as we see from name is “Model-View-Controller” framework (powered by .NET framework), so use actually concepts of “Models”, “Views” and “Controllers”. “Views” and “Controllers” concepts defined by framework itself (i.e. you need to inherit controllers from System.Web.Mvc.Controller class and inherit views from System.Web.Mvc.ViewPage to use build-in view engine). It is also possible in ASP.NET MVC to attach third-party View Engine (just google and you will found at least few). But “Models” concept in ASP.NET MVC is true “concept” – you don’t need to inherit from some base class or implement some interface to made a models in ASP.NET MVC! Instead framework provide you will full flexibility to create your own domain model and select any persistent framework if you need to persist your model entities. You can use for example Entity Framework, Linq to SQL, any other ORM or even POCO to implement your models! 2) Ruby On Rails is true “Model-View-Controller” framework and more so it uses “convention over configuration” principle. This mean that you actually have already defined conventions where to put your model entities, where to put controllers and where to put views (templates) and how to implement them (from what class you need to inherit etc). Sure while it is still possible to made some changes and even use another ORMs etc, build-in (OK, read instead “installed by default with Rails”) ActiveRecord ORM is enough for most cases (OK, at least in most simple cases ). The same things with templates (views) – you can use build in template engines (provided by ActiveView module) or add your own – at the time I write this exists not less then 20! different third-party template engines in addition to build-in (sure you can always build your own if need and made 21-th)! 3) Grails is really “Model-View-Controller” framework, was build with same principles like RoR, but because Grails work on top of Spring and Hibernate, developers initially get BEST build-in enterprise infrastructure from Java world! And sure in Grails infrastructure was extended so much (thanks to power of Groovy), that it looks like it most powerful MVC framework to the moment (this is just my personal opinion – I don’t want to start a war here )!
So frameworks listed above all follow MVC terminology where you actually create your own Models (Domain Models possible with Persistence), implement Controller (with actions) and create presentation using Views (that is actually powered by some build-in or custom template engine).
One framework – Django – that we use for Evejob project made use of a little different terminology (instead of MVC): Model-View-Template. Model term is used for same purposes like Model in MVC – it is simply domain model (provided usually by build-in to Django ORM, but also possible to use your own ORM… just note that it require little more “tuning / hacking” than in other frameworks). View in Django play the same role as Controller in MVC. And “Template” term in MVT actually used instead of “View” from MVC (while Template terms actually also used in MVC in sense that view CAN be represented as result of Template rendering) What I found from my experience that this difference in terminology does NOT make any actually impact on development process! More so, actually most MVCs that available in the market used mostly in “MTC” mode – i.e. “Model-Template-Controller”. What does it means? It means that Controllers actually render Templates in MOST of the cases! Sure in case if you use MVC framework to build for example Web Services, you will probably not render any Templates and your controllers (controllers in MVC or your Views in MVT) actually more likely will return JSON or XML directly (OK… XML it is possible also to build using Templates sometimes – look how it is done in Grails for example! But let’s think here that we want to return raw XML from Controller without any template engine). Sometimes you also can return JavaScript or any other format etc directly from Views in MVT or from Controllers in MVC. What is good in MVT is “order” of letters that give better understanding for developers that first time here about this pattern – “Model” <-> “View” <-> “Template”. This way logical flow going – i.e. views are in the “middle” of this logical flow! (using this principle it was better initially probably call MVC as MCV, i.e. “Model” <-> “Controller” <-> “View” , so “Controllers” become in the middle, center of logic). It related only to logical structure, because in MVC pattern, Model accessible (and used) actually in both Controller and View, same like in MVT both Views and Templates share same Model! You can read a short overview of MVC at Wikipedia article for example if want little more information) But as I tell before – main thing is “understanding” how pattern works, not how we call it! And “idea” of implementation of this patter in Django and other frameworks is exactly same even so name is not!
From use cases of Sprint #1 and from our general initial understanding of business domain (Job Board) we can grab following main domain entities:
It seems like it’s enough entities to start – I highlight them in bold, totally 7 entities seems a good number actually!
So let’s start actually coding of domain models Check next posts!
OK, now it is time to go deeply into business domain of Evejob – Social Job Board and made small Agile project management.
What we know about Job Boards in general:
This is “base, common, required” functionality that looks like MUST be present (with some adjustments) in any Job board so both Companies and Job Candidates found board useful!
Despite the fact that I have very important extension to such “base” functionality which will made Evejob project Unique and more “Social”, I still understand that base functionality must be done before… In any case, I will need to use such business domain entities, like “Company”, “Job Candidate”, “Job Post” etc. So instead of spend my time now describing what made “Evejob” really unique let’s just start “base” implementation and move forward…
But how to start?! This is most problematic question… Do I need to made “big design upfront” or? Do I need to describe all use cases (made 100s screenshots etc) or I need to start coding right now etc? In general answer as always: “it depends!”. But in my case, I can simply start from small and using iterative approach continue development… But anyway, at least small plan will help me to be on track and help readers to understand what will be in next iterations.
So here is the plan that I take from project backlog for Release #1 (at least like I see it right now… I did not want to put here full project backlog for some trivial reasons…):
Release #1. Base Job Board
You can ask: why this specific order??? Why I am going to build for example Employer stuff before Job Candidates? Answer – from business point of view! Our goal to build software that can be used even after just few iterations, so what sense if for example I will made first Job Candidates resume management and made release of this? Who can use this? Nobody – it will be just catalog of Job Candidates resumes… Nobody will want to register, nobody will add own resume if he will understand that nobody will search for it as search still does not implemented on site!
But look at order that I select: if we implement first Companies catalog, then we can made release, even put application to hosting servers and start fill it with local or even worldwide companies – start to promote site to such companies, let them send us description information, add this information to our database… etc… Maybe even made some “special” pages for huge companies like Google or Microsoft And while we will made next X iterations, we will simultaneously improve our companies catalog, extend our public relations and promote our business! Here we follow principle: “Release Early” (feel free to overview also other important principles that I follow in my projects). Also it is very important that doing such “early” release we will start getting feedback and start to dial with real production environment! It is specially important in cases, where you plan to host your application in “special” environments - Azure, Google App Engine are some examples of such environments – you simply don’t have full control, so as early you start, as much “problems” you will face and fix in initial steps!
I put Sprint #1 – Sprint #7 into “Release #1″ because I think (at least now) that we can call “Evejob” project “version 1″ only after Spring #1 – Sprint #7 will be done and not before as all this functionality required for any job board application! As I tell before – it does not mean that I will put site into production only after complete all 7 sprints – I will be Agile and at least for now I see that it make sense to put site into production right after sprint #2…
For those who want to know little more, I will put here overview for next few releases:
Release #2. Following
This what will made site unique – “Follow” principle, something like Twitter but for Job Boards Want to know more – just stay with me
Release #3. Search
This release will be dedicated to different simple and advanced search features.
In next posts I will go deeply into each sprint, so stay tuned!
