Structure
Overview
Where possible, we should lean on a well-known framework for initialising new sites.
Using a well-known framework comes with numerous benefits and few drawbacks. Some of those benefits include:
- Security releases
- New useful features
- Easy to upgrade to new versions of the framework
- Helper utilities built-in
- Great documentation
The drawbacks include:
- Can end up tied into a specific framework
- Framework may be deprecated
- Usually includes more than it needs to (bloat)
Which frameworks?
Whilst any well documented and supported framework would suffice, at Built By Cactus, we tend to reach for Laravel as it meets all our requirements and is well tested.
If you do think about using something else, please take a moment to weigh up the pros and cons of switching away from the currently known framework. What is the learning curve like? How will that impact the delivery and maintainability of the project? New shiny frameworks are great, until something goes wrong!
Controller Structure
At Built By Cactus we like to keep our code as lean and dry as possible. A big part of this is making sure we don’t overload our controllers with application logic.
Whilst some people like to move their logic from the controller to a model, we think this is still wrong and promotes bad practices. Instead, we opt to use the Hexagonal Rails Architecture.
There’s a great video on it here.
The hexagonal architecture views the application as the hexagon in the middle. Every side of the hexagon represents some sort of dialog the application needs to have with the outside world (e.g., talking to the database or interacting with the user).
It means that our application logic is separated from the code that uses it. This does two things:
- Make our code easier to test in isolation.
- Makes our code more reusable. E.G. Web interface, API, CLI can all use the same logic.
As such, we implore all engineers to use this architecture when working with MVC.