The older I get the farther I can see

Don't worry, this topic is not about eyesight. Rather it is a reflection on items that have become clearer through years of experience about creating enterprise software. Today I'm going to discuss object oriented programming (OOP), MVC and APIs.

I was first introduced to object oriented programming via Smalltalk in the mid 1990s. It seemed quite radical at the time and required to really challenge your thought processes on software construction. Of course today, OOP is everywhere and seen in every modern programming language. Most millennials probably don't know that MVC (Model-View-Controller) was developed at Xerox PARC 35+ years ago. A quick look on Wikipedia will give you a good history of MVC. MVC came via Trygve Reenskaug as a visiting scientist in 1979 and embodied in Smalltalk-80 by numerious folks at PARC. Smalltalk was one of the earliest OO programming languages that adopted MVC.

When developing enterprise software solutions, modeling the business domain into objects is a must do task. There are many modern frameworks today that try to shorten the on ramp to creating enterprise software. The problem I have with many of these is that while you can launch a project quickly, you run into major issues later because the domain can't be properly modeled or is ignored because the framework is focused on rapid development of usable software at the expense of long term sustainability. Why is modeling domain objects important?

What experience has taught me and what has become self evident are:

• A solid domain object model can last for years if not a lifetime resulting in a long term reduction in software maintenance expense.
• A well defined domain object model can transcend changes in technology

The cost for developing enterprise software solutions can be quite high. If you've done it once in your career, you don't often want to do it again.

The domain model of objects has nothing to do with what the software looks like. These are objects that represent your real world business elements. They have attributes and behavior. Example objects could be a Location, Person, Invoice, or an Order. Objects have methods that allow you to interact with them and between objects. Adhering to the core principles of OOP (encapsulation, inheritance and polymorphism) will ultimately produce a domain model of objects that will reduce your long term software development and maintenance expense.

I'm sure most of would agree that we would prefer the first chart to the second chart in predicting your software development expenses.

Object oriented approach

Non-object oriented approach

I've had the fortune (or misfortune) to witness and participate in both. The second siphons the life out of the organization and developers as it seems like a non-stop treadmill of issues. It makes it extremely hard to innovate. There are some, though, that like the second chart because it creates job security.

I've used the term domain model because I want to sharpen the M in MVC into 2 components. First is the domain model and secondly there is an application model. The MMVC pattern is a refinement from the original MVC concept proposed in the late 1980s. In the MMVC pattern, the domain model is what I've described previously. It does not have knowledge of the ways the outside world can communicate to it. It doesn't know about web requests or web servers. On the other hand, the application model does know about the outside world and acts as a coordinator in receiving requests from the outside world and using domain objects to respond to the request. The application model knows about things like HTTP headers and CORS. The domain and application model separation is critical in achieving long term sustainability with enterprise software solutions. It goes to the heart of my second point above... technology trends come and go so create an application architecture that can adapt to the trends. There are plenty of examples of web frameworks that keep popping up each year. From Django, HapiJS, Express, Grails, Meteor, Cake, Ruby on Rails, Flask, ASP.Net MVC, etc. Who knew 5 years ago that NodeJS would be as dominant as it is today?

The point is we know technology will change. It is up to us as technology professionals to create sustainable solutions that can adapt to the latest trends. This is why I named my company Endring (change in Norwegian). I embrace change and know that by using OOP in a MMVC pattern, I can create enterprise solutions that will cost less over the long run and adapt to changes in technology.

My last topic is about creating RESTful APIs. If you read the original HTTP spec, a literalist can see it proposes to use the verbs (PUT, POST, DELETE, PATCH, GET) to perform specific actions. Clearly, over the years, the majority of usage has been with GET and POST requests. But recently, RESTful purists argue to use the verbs in their original literal sense.

• GET = retrieve information
• POST = send an entity for processing
• PUT = add an entity for storage
• DELETE = delete a resource
• PATCH = update a resource

I have no quarrels over people using this approach. I just believe it is short sighted when developing enterprise software due to a duplication of code. The normal RESTful approach will use the url to identify the data elements to interact with on the web server.

GET http://api.example.com/v1/state - would retrieve a list of states
GET http://api.example.com/v1/state?name=IL - would retrieve Illinois data

This works great for simple applications. Enterprise applications normally have much more complex rules. How do you embody the following rules into URL parameters?

Retrieve invoices where the outstanding balance is greater than or equal to $1000 and days outstanding is greater than 30 days OR where the outstanding balance is greater than or equal to $500 and days outstanding is greater than 60 days AND any invoice generated in the last 5 days.

I've seen some crazy url encoding schemes in order to adhere to a purist approach to the RESTful APIs.

The HTTP spec was written in 1999. As much wisdom as they had in the creation of this spec, I don't think they could have predicted where we are today. So rather than a purist approach, I've come to learn that using the POST method for transmitting data to/from the browser and server is the most efficient and consistent method with enterprise software demands.

As an example, I can easily represent the previous rule in a JSON object like the following that is submitted in a POST request.

{ "action" : "retrieve", "object" : "invoice", "criteria" : { "and" : { "or" : [ { "balance" : { "ge" : 1000 }, "daysoutstanding" : { "ge" : 30 } }, { "balance" : { "ge" : 5000 }, "daysoutstanding" : { "ge" : 60 } } ] }, "invoicedate": { "le" : "now() + 5 days" } } }

In this example, I can represent the action needed (get, insert, update, delete) as well as the object I want to operate on using complex rules. I can use a single application model to handle each action across a wide variety of domain objects. I don't have to duplicate application objects to handle every new domain object that gets created. This is one of the advantages of this approach over a the more literal approach of creating separate handlers per action verb.

In conjunction with OOP and MMVC, this type of API construction becomes a repeatable pattern and easily transferred between any programming language and web framework.

Every methodology and web framework have opinions embodied in them. While this discussion is my opinion on the development of enterprise software solutions, it is backed up by historical patterns and real world experiences. I firmly believe you can achieve faster development at a reduced overall lifetime cost with this approach.