32 lines
1.5 KiB
Markdown
32 lines
1.5 KiB
Markdown
|
---
|
||
|
|
title: Why write framework-agnostic code
|
||
|
|
date: 2024-03-05
|
||
|
|
permalink: archive/2024/03/05/why-write-framework-agnostic-code
|
||
|
|
tags:
|
||
|
|
- software-development
|
||
|
|
- php
|
||
|
|
- clean-code
|
||
|
|
cta: testing_course
|
||
|
|
snippet: |
|
||
|
|
Why you should consider separating your business logic from your framework code. What benefits does it offer?
|
||
|
|
---
|
||
|
|
|
||
|
|
[Yesterday], I wrote about writing layers in your application code and the benefits of loosely coupled code.
|
||
|
|
|
||
|
|
Something else you can do with this approach is to write framework-agnostic code.
|
||
|
|
|
||
|
|
By writing your business logic in code that isn't tied to a specific framework or CMS, with a small adapter layer, you can upgrade to a newer version of the framework, such as Drupal 7 to 10, or a different framework, keep most of the code the same and only update the parts that connect the business logic and the framework.
|
||
|
|
|
||
|
|
This is something that Commerce Guys (now Centarro) did when creating Drupal Commerce 2.0.
|
||
|
|
|
||
|
|
The logic around addressing, tax, etc., was released in separate PHP libraries, each with its own release cycle and reusable logic.
|
||
|
|
|
||
|
|
This meant the Drupal modules were much smaller, and other eCommerce systems and frameworks could use the agnostic libraries.
|
||
|
|
|
||
|
|
It's something to consider when writing your next Drupal module.
|
||
|
|
|
||
|
|
It's something [I did recently][nre parser] and have done on client projects previously, and it can be a good approach.
|
||
|
|
|
||
|
|
[nre parser]: https://github.com/opdavies/national-rail-enquiries-feed-parser
|
||
|
|
[yesterday]: {{site.url}}//archive/2024/03/04/why-you-need-layers-in-your-application-code
|