MVC 4, Django Research

In earlier posts I’ve talked about the necessity of research.  I always keep my eyes open for new technology.  At DealerOn we are about to embark on a new and major project (of which I can’t give details at this time).  All I can say is that it will be a complete ground-up design.  At this point all possibilities are open.  We have kicked around a bunch of ideas on how to design this new web application.  Django with Python is still being considered and I have done some preliminary analysis of Visual Stuido’s Python/django implementation.  My first assessment of this implementation is that was should go all in or don’t attempt it.  In other words: Stick to Python’s native OS (Linux) so we are relatively assured that we can build this web application without running into technical problems part way through the project. 

The other environment I was researching is MVC4.  Specifically the Web API with AngularJS.  I found a CRUD sample application that has AngularJS with Web API and it works rather well.  My only real turn-off was the sheer number of source files it took to make that beast run.  Here’s a link to the code: CRUD grid using AngularJS, web api, Entty Framework and Bootstrap.  One other appealing aspect of this project is that it uses EF and bootstrap (bootstrap provides responsive design for portable devices). 

In addition to downloading samples from the web, I have purchased two books to read and gain further insight to these two frameworks (django and MVC).  The first book is for django:

I only thumbed through this book so far, but I own a lot of Apress books and they’re generally good for information. 

For MVC, I purchased this book:

 
 
I started reading this book yesterday and I have to say that I like this book a lot.  If you have never done MVC programming before, buy this book.  It starts with an empty project and has a chapter on one concept at a time.  The first concept it covers is the controller.  The first test programming is nothing more than a controller source file that returns a string.  The chapter describes the default controller names (“HomeController”), the default controller directory and how to use controller methods.  This is all taught without regard to views or models (covered in successive chapters each).  The appeal of this method of learning is that you can lean one concept before moving on to the next.  I have looked at a lot of examples and reverse engineered some of this stuff from the examples (like the Web API interface, I learned by reverse-engineering a working example).  My knowledge is much more solid when I can focus on one piece at a time.
 
So now you’re probably thinking “Frank, you’ve never done an MVC project before?”  Nope.  The reality of software development is that you only get to use a new technology when you create a new application or rewrite an existing application from the ground up.  After that, you’re stuck for a long time with the technology you have chosen.  So choose wisely. 
 
I typically try to choose a technology that has been around for a while, that way all the quirks have been discovered by other developers and the answers are posted on forums like Stack Overflow (Stack Overflow, in case you don’t already know, is the holy grail of answers for programming problems).  I also strive to choose something that is close to bleeding edge so I know that it won’t be obsolete before I deploy the first application (i.e. I could just create this new app as a standard ASP code-behind application and be done with it.  But that’s really no fun and I hate code-behind pages).  Currently, frameworks are all the rage and there’s a reason for it: Separation of concerns.  It is easier to maintain an application if each file or module is concerned about one aspect of your application.  Concerns are like database access, URL routing, Business logic, views, etc.  By dividing these tasks into different files or modules, the developer can focus on one aspect at a time and not mix it all together in one source file (remember ASP?  Yuck).
 
When I first looked at a demo of the MVC setup, I was a horrified by the fact that there are three primary directories to contain all the major code files for the web application (The Model, View and Controller directories).  In a real-world application, I can visualize these folders growing to thousands of files each.  However, I have another plan for our application.  I plan to leave the model directory empty and wire the controllers directly to the business objects, which will be contained in a separate project or projects.  All the database Entity Framework stuff will also be in a separate project.  This will give a clean break between the web side of things and the business code for unit testing purposes (and the ability to use the business code for other applications, if necessary). 
 
Django
 
I spent some time looking at django and Python for Visual Studio.  If you’d like to experiment with this setup, go here: Python tools for Visual Studio.  There are a few tricks to overcome to get django to work properly, but they’re contained in the samples.  One turn-off is the amount of stuff needed to be installed and configured before it will work at all.  However, I’m willing to overlook a difficult configuration if it is only used to get the project started and running.  The appeal of the demo project that I looked at was the minimal number of files that were necessary to make it work.  Django was designed to just get things rolling and it certainly does that (once the initial configuration and setup hurdles are crossed).
 
My purpose in testing the Visual Studio version was my hope that it would work as a project within a solution.  In other words, I was hoping to create my business logic in another project (i.e. assembly) and just reference it in my Python code.  This doesn’t seem to work with the 32-bit version of Python.  The 64-bit version of Iron Python doesn’t seem to work with django (or perhaps I haven’t stumbled on the proper way to install django yet, since Iron Python doesn’t use pip for installations). 
 
Another avenue I explored was to connect to SQL Server from Python.  There are database connectors for SQL Server and there are a lot of people having issues with it.  The whole SQL Server part has it’s own drivers and requires other software to be installed and configured.  I have a lot more research to do on this subject.
 
The django avenue will create other issues with our environment if we decide to go that route and there is no ability to import and use objects from C# projects.  One issue will be the ORM that we use.  It will have to be an ORM that is native to django.  We would also need to verify how compliant any SQL Server driver is, so we know up front if we are digging a big hole for ourselves.  We are not in a position to convert our database from SQL Server into any other technology at this time.  Our database is currently tied to other applications and it contains a lot of stored procedures.
 
Conclusion
 
At this point you’re probably thinking that I’m biased to using MVC because most of my recent development work has been in C# and SQL Server.  However, I have switched technologies in the past.  I have built large web applications using PHP and Oracle all on top of the Linux OS.  So I’m not tied to Microsoft.  I have also ported a PHP/Oracle system to C#/SQL Server, so I know how to switch between two different technologies.  My gut feeling at this point is that I need more knowledge of both MVC and django to make a more informed decision on which way to go.  This decision will probably be sooner than later, since I really want to get the show on the road and this project has been on the back burner for too long already.
 

Leave a Reply