How to Organize Your Software Development Project Part 1: Theory

In software development, you will often be handed a large task or feature to develop, especially if you are starting development on a new project.? How do you start with splitting up tasks for development?? In an ideal world, how do you plan to implement a new application?

The Model-View-Controller Framework

Early on in the history of software development, the concept of a framework which separated parts of the application was introduced; splitting up Models that talk to a database, Views that are presented to the user, and Controllers that guide the user from screen to screen on an application, or web browser.? This was eventually called Model-View-Controller, or MVC.

While this is a great idea for a first step in creating a new application, there are several drawbacks:

– This is supposed to keep the code in small and understandable pieces, but doesn’t take into account a fourth, very important part of any software application: business logic.? A bit more on this below.

–? Implementation of MVC often requires knowledge of multiple languages, as the View component may be written in a language specific to the user interface, but the Model component may have to be written in a language specific to its database.

–? While the code in a MVC product is split up into smaller parts, the developers will still require some kind of a plan or scheme to track the user flow through the whole application, otherwise they may not be able to find all the specific parts. Think of a larger application that may have ten to fifty user screens to complete a process; will there be one set of controllers or views for every screen? Will there be one large controller to process it all? Neither situation is very ideal.

Major Pitfalls

Let’s talk a little more about that first point, as it’s a major pitfall of the MVC way of designing a program. What was overlooked by the original idea of MVC was the fact that business logic is also a very important part of every application.

An example of business logic would be in a banking application; your Controller would handle logging in, your Model would fetch data about the user from the database, and the View would show balances and accounts. But suppose your account was past due, or you were granted a car loan, or a credit increase? Where would the logic ‘live’ in the application to show the user these announcements, or direct them to another page to pay off the account?

More often than not, this code was in the Controller, but to be honest, this could have been placed in the View or Model as well. If you created a ‘classic’ MVC application and it grew over time, it could be the case that different parts of the business logic could be in all three parts.

The Need to Account for Business Logic

To replace this framework, other solutions have been proposed, each of which try to remove this ambiguity of ‘where to place the business logic’:

– Model-View-Presenter (MVP), where all logic is pushed to a Presenter level – Model-View-ViewModel (MVVM), which combines logic within the Models only

There are many others which have been proposed since MVC, such as Multi-tier architecture, Presentation-Abstraction-Control, Hierarchical-Model-View-Controller, and so on.

What we’re describing above are just the first steps to thinking about how to organize the application.

Even when you have a plan to build a new application, however, external needs may force you to change your plan. Come back next month where we talk about Part 2: Practice.

More resources about MVC and many other architectures can be found here:

– https://www.geeksforgeeks.org/what-were-the-major-problems-with-mvc-framework/ – https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter – https://en.wikipedia.org/wiki/Multitier_architecture – https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel

To learn more, contact us on our website or email us at ?[email protected].