Welcome Guest, Not a member yet? Register   Sign In
Where should logic go [edited]

(This post was last modified: 02-19-2017, 12:01 PM by ciadmin. Edit Reason: Modify example )

Hi, I'm building my CI structure. Is it a good practice to separate the logic in the controller? My goal is to make controller act like a router and just use the logic classes with namespace support.

Here is my build: https://github.com/marksagal/CodeIgniterPlus.git

- You will have to point your DocumentRoot to ./public
- You will have to manually create ./application/cache/views/


- CodeIgniter-minify
- Blade template engine

How to create logic? create a file in logic folder in Studlycase (Myclass.php). The class can be namespaced, then use your class by adding use yournamespace\Myclass in your controller  and just instantiate it and its ready to be used.
e.g: ./application/logic/Store/Car.php = \Store\Car::myMethod()
(Convention: every Capital letter in class and filename considered another level of directory)

Please suggest ideas because I will be building a longterm project. I prefer the best practices.
God Bless CI Contributors Smile

Slim controllers and fat models. Your controllers should just pull data from libraries/models.
Codeigniter is simply one of the tools you need to learn to be a successful developer. Always add more tools to your coding arsenal!

(02-19-2017, 09:39 AM)albertleao Wrote: Slim controllers and fat models. Your controllers should just pull data from libraries/models.

That was one of my goal in separating the logic in controller. But I really dont want to use library to be part of my logic. I just want to act library as a helper and controller as a router. And I dont want any logic on my model just pure queries.
God Bless CI Contributors Smile

You'll never get a perfect separation like that in reality.

This is why template engines like twig and blade often contain "if" blocks.
Practical guide to IgnitedCMS - Book coming soon

Practically, I've formed this opinion:

- thin controllers as much as it is possible;
- fat models which can call each other for complex logic;
- views without business logic. Logic that solves visual/design problems is allowed; "logic-less" templates are extreme as an approach.

the controller issues commands - anything 'specific' about those commands belongs in a model (or a library or config or...)

plump controllers that get refactored to thin controllers
fat models that get refactored to models with specific tasks inside a directory folder

thin controllers with declarative method names:
displayAllBlogPosts() or searchForBlogPostBy($id)

fat models that get refactored to their own folders
with bigger applications, its much faster to open the model folder
and then see a nice clean directory structure with relevantly named folders
then you can quickly dig into the appropriate part of the project to work on the appropriate models

refactor so there are no validation methods in the controller
again the controller issues commands - the method in the controller asks - did this form validate or not?
is this user logged in or not? its not concerned with the names of a form field or what kind of validation is being done.
then you can update your form validation - and very importantly - your controller code does not change at all.
the change is constrained to a specific part of the application that is just concerned with validating the form.

Theme © iAndrew 2016 - Forum software by © MyBB