Welcome Guest, Not a member yet? Register   Sign In
how to choose a good software architecture
#1

[eluser]aligator[/eluser]
Hello,

being new to codeigniter, the first atempt of project goes well. A question is in my mind now: what is best practice in concern of architecture of the application using this framework?
So far, all php files are placed in their correct folder: controllers, model, views..

What if the project extends, is there a better way of separating the features on each level besides creating new folders on each level? i mean in controller to have a folder called "authentification" and another folder "operations" etc. (same name folder in models and views).

I am asking this, to know the oppinions of the more experienced developers on better practices and because i do like to see the features being structured and nicely arranged.

Thank you. Tongue
#2

[eluser]Davcon[/eluser]
I think it's a really good question and I'm sure everyone has their own way of doing things.

Personally speaking, I don't do folders within the main MVC folders. My own strategy, as of late, is to try to have as few controllers as possible.
#3

[eluser]tonanbarbarian[/eluser]
As david said everyone has their own way of doing things

David I would actually suggest that more files is better than fewer.
If you try to cram everything into a single controller, a single model and multiple views you will ultimately be slowing down your site, because PHP will have to parse and process large controller and model files
It also can become harder to maintain the site as you have to hunt through large controller files to find things you need to change

if you split your code into multiple small controllers you can reduce the amount of code that needs to be parsed and processed per request and that should improve performance by being quicker to execute and using less memory.
If your site is ultimately going to have low access rates then it will not be noticeable, however if you try to stress test your site you will notice that it slows down very quickly and uses a lot of resources.

If I have a controller over a few hundred lines of code I try to either split the controller or if I cannot split the controller I move all of the code from the controller into several logical library files and then get the controller to call the libraries instead.

Remember that when you call a page the controller will generally be calling just 1 method from the controller. If the controller has 20 methods in it that is 19 methods that are not needed to service that request.

I am not advocating putting each page into a separate controller, but you need to balance things if you want performance.

The same consideration should be taken for models, however to date I have not ever split a model into several files or even into libraries. all of my models I have just kept as a single file.
#4

[eluser]Davcon[/eluser]
Brilliant post!

I'm going to counter what you've said but please realize that I'm not doing this as part of some debate. I'm not even trying to convince you that my way is best. However, I do want to set out an alternative viewpoint. If you can convince me that I'm wrong then I'll be eternally grateful.

Anyway...

I think there's two great advantages with doing things my way:

The first advantage is that my way is much more easy to manage, tweak and upgrade. Right now one of my websites is top 5 on Google for "website repairs". Last month I did a repair job on a CI website that was built in the manner you've described. Wanna know how difficult that job was? Well get this- the guy who originally built the site ended up walking and has now quit his career as a web developer. As for me, I no longer do website repairs. That's how unpleasant it is to upgrade one of those sites. They are career breakers!


The second advantage of doing this my way is related to the Holy Grail of PHP. Think about the reasons why you decided to use a PHP framework in the first place. Wasn't one of your main motivations the idea of being able to build custom web applications really quickly?

With my method there is a much better chance of getting the Golden Grail. So, I can build a feature of some sort and if I want to use that same feature on another site, I just grab a small group of files and bolt them onto the next site. Your method, unfortunately, makes the whole bolt on concept very difficult because everything has been broken down and spread out across a variety of locations.

I agree that very large controllers might be slightly slower to load. However, in reality most controllers never seem to require any more than seven methods- not twenty. The effects on website load speed appear to be insignificant.

Take a basic online shop for example. It could have one controller called basket. For that controller to work, all it needs to be able to do is; add items, delete items and display the basket. That's it. No need for twenty methods there.

I think it would be quite easy to build an entire online shop with just a small handful of controllers:

-items
-basket
-webpage
-admin
-checkout

Just a few thoughts.

Cheers!
#5

[eluser]Vheissu[/eluser]
The best architecture of a CI app is to use Modular CI or my favourite Modular Extensions to give CI HMVC capabilities. That way you can organise functionality into module folders to make updating and editing easier. Because a module is basically a separate application, you only need to make one change in your module to affect your entire codebase.
#6

[eluser]tonanbarbarian[/eluser]
David I think we are basically on the same page

I am not saying split controllers for no reason, only if they become huge. I would never split a controller that only have 7 method in it.
I actually base my controllers around the model which is based on the table
So for example if I have a user table then I will have a model called User and a controller called Users that will handle most if not all of the interactions with User model. Finally I have a view folder called users with any views the controller will called. This way everything in contained.
If I have admin controllers they generally go in a admin folder, and if it turns out that the admin and front end controllers are generally performing the same actions, they I will put the common code into a library and have the admin and front controller call the library rather than replicating code.

I feel this makes it easy to transport my code around

What I was trying to point out was if you try to put an entire sites worth of code into 1 or 2 controllers and try to manage that it would not be workable andwould be slow.

Sounds to me however that we have similar approaches
#7

[eluser]Davcon[/eluser]
Yes, we probably are indeed- although I suspect you're more expert at CI than me. I talk a good talk but I'm still quite new to CI and still have lots to learn.

I've been Googling HMVC and also PAC like crazy since this thread started. But all of the articles I find come in too deep for me.

Does anyone know where I can get a complete idiots guide to hmvc or PAC? I'm interested in learning more about it and I'd be willing to pay for tuition, if it's easy enough to learn.i
#8

[eluser]smilie[/eluser]
Well, what you are both saying is same:
group all logical application executable code into controller <> model.

Users controller <> users_model
Admin controller <> admin_model

In one of my applications I did use sub-directories in both, but this was because same CI was used for several brands. So I ended up with:

Controllers
- Directory Brand A
- admin_controller.php
- users_controller.php
- ...
- Directory Brand B
- admin_controller.php
- users_controller.php
- ...

Same goes for models and views.
Libraries and helpers are used by all brands and therefore are all in one directory.

Cheers,
Smilie




Theme © iAndrew 2016 - Forum software by © MyBB