CodeIgniter Forums

Full Version: Help to apply onion architecture in codeIgniter
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
I am new in codeIgniter I have read a book "The clean architecture in php" by Kristopher Wilson which says that If I apply the onion architecture, I will become more free in the dependency  of the framework.Also that book have a example with ZF2. How I can start to apply the onion architecture in codeIgniter?

Effectively you have to split and organise your code between controllers and models in a way that separates logic from presentation, which is easier said that done.

Here's an example in Laravel, but same principles should apply:

He has first example where some of the default values are set in controller level, where it makes much more sense to individual model to handle that, so in second refactored part he's moved it to model side.

Personally I don't agree where he has put his shelf validation, but I'm not familiar enough with official definition of "onion architecture" to argue if it also should or shouldn't be handled by model.

Also, not sure how much framework dependency this would give you, CodeIgniter in at least in 3.x, and I imagine Laravel too, the models are pretty integral to how the core framework works, and relay heavily on framework base code to handle specific things for them.

Any particular reason you are worried about framework dependency so early on?
I want to apply the Onion Architecture or the AKA Uncle bob architecture because in the book that I have some examples that gives toy the opportunity to separate the business logic from the view and framework and also you are independence from databases. You can change php framework very easy. You can see a clean architecture project
Go to the page 69.
An even easier way to get your "onion architecture" is to use CodeIgniter 4.
It shares most of the same goals as the onion, namely independence of the UI, database, and external agencies. It has adapters (or handlers if you prefer that term) to bind your app to other "stuff", and the model/entity/persistance mindset (if I interpret the article correctly). And it is testable.

One thing CI4 doesn't have, from an "onion" perspective, is the "independence of frameworks" aspect, unless you consider CI4 to be a technique for achieving that Undecided

Just sayin' Smile
Have you a tutorial to show me ?
We have the standard tutorial -
More interesting, though, would be some of the blog entries from Lonnie Ezell, the lead developer ...
This is not tutorial with clean architecture.
(11-30-2018, 01:30 AM)Death_Soldier Wrote: [ -> ]This is not tutorial with clean architecture.

Agreed - it is a "comfort" tutorial for those coming to CI4 from CI3.
That is why I mentioned Lonnie's blogs - they explain the independence better.
I don't know if he has a tutorial though, let alone one for "onion architecture".
(11-29-2018, 03:38 PM)ciadmin Wrote: [ -> ]One thing CI4 doesn't have, from an "onion" perspective, is the "independence of frameworks" aspect, unless you consider CI4 to be a technique for achieving that Undecided

Hmm, I dunno, but I'm feeling a bit skeptical about the practicality of truly "framework independent" approach.

So let's assume you can easily switch out database layer with any other DB library.

You'd use entities with CI or Laravel Eloquent to automate/standardise how your models behave.

If you don't want to be framework dependent, you would either have to manually do everything on every single model you write, which IMHO is not practical and is breaking Don't Repeat Yourself principle, or you'd have to write your own custom model extension layer to replicate everything CI/Laravel already gives you out of box.

I don't think (and I have not looked) any mini-framework gives you routing only, or templating/views system only, or model layer only, so just picking and choosing different libraries for different layers is not really a path PHP developers can take at the moment.

Best you could do, again in my opinion, is try to separate concerns in different layers, and that makes 100% sense even if you don't plan to swap frameworks, but accept that you are using framework for a reason, just aim to keep it nice and tidy in right place so moving from one to another is easier task, but still takes manual changes to swapping out one frameworks model handling for another.
Do you have a nice tutorial how to apply SOLID principles in mvc? You mean to become independent of the framework is not good idea?
Pages: 1 2