CakePHP is fantastic, it really deserves the slogan "Rapid Development Framework". I have been able to quickly bake controllers, models and also templates. Things were good for a while until I hit a brick wall. The application I'm developing is way too massive for the simple directory structure offered by default.
Half way in my development process, I started to see myself leaving lots of business logic inside of Table classes. I've heard sayings that it's not a good idea to pollute the model class with behavioral code.
Since my application is large that it requires several modules almost mini applications by themselves I need to use CakePHP a little differently. I will explain the structure of my application that I would prefer.
Application Structure (Architecture)
Core
This folder will contain all the modules my application is made of. Alternatively it should be called "Modules" instead of "Core".
Modules
Each module folder will have a folder for Controllers, Models, Services and Templates.
Model
This will contain two sub folders as the ones already offered by CakePHP 3. It will contain the folders for Entities and Tables. I have heard the table acts as a repository so I have omitted the idea of having a repository folder.
Service
The service folder will contain services for the module, mainly business logic code that uses Table Entities for data persistence and retrieval. This is to help keep the business logic centered and keep the model classes & controller thin.
Controllers
Controllers will be the ones talking with the service classes. Using the services to both retrieve data, save data, do validation, work with business logic...etc. My goal is also to also make the work of the controller very light, by moving most of the logic stuff into services.
Template
This will contain the view files that the controllers will use to render data back to the web browser. I might have sub folders in there for views for sub sections of the module.
Notes & Questions
Please forgive me If I have not explained my self properly, we are dealing with a very complex application that has many tables, approximately 100. If anyone has better recommendations for organizing a large application in CakePHP 3 I would really appreciate it.
By developing my application in this way I understand CakePHP will not work out of the box, I might need to reconfigure it so It can uses my custom directory structure. How easy will it be to do that?
Related
When should we use multi-module structure (instead simple structure) in php Phalcon?
I have found some multi-module skeleton, such as:
https://github.com/ovr/phalcon-module-skeleton,
https://github.com/phalcon/mvc/tree/master/multiple.
But I don't know should i use this multi-module structure in a project instead use multi projects.
Something i can think about it is: more complex configuration, complex folder structure, my web url be longer (/[module]/[controller]/[action]) and , importantly, performance will be low (for more loading things than).
However, I think that there are something interesting with it (so many ITer had used it). Is there Someone can give me advantages, disadvantages and criterias for selection.
P/s: the same problem with Zend2 Module!
If you are building a single purpose application as an API that does not use Views, you should rather use single module structure. If it will be a realy simple API of for example storing/logging, micro app will do aswell.
Multi module application structure is useful if you are willing to build more complex solutions. For example an public application with public content, but with admin panel. This one would be handy to write in multi-module to separate administrative controllers/views from those public ones.
My habit is to use multi-module structure, because mostly I have to build applications that are CRM's with their API and an public accessible content part (eg. docs). For such purpose it's just handy to create such modules as:
frontend - for controllers accessible by everyone
backend - for controllers accessible after authentication and authorisation like administrative things
API - for API purposes ;)
common - a part I rather am willing not to implement, but in one project I'm forced to put here some abstract controllers that will be extended in other modules.
This way you can keep separate services configuration for each module, what saves you from cutting off things that you are using at purpose of module A, but not on module B. Like authentication part - important for backend, but useless for frontend part. Or Database configuration - slaves for frontend, master for backend, etc. So this may be also a performance-wise solution for big projects.
Update
Sometimes "multi-project" is an option including "multi-module" project ;) It strongly depends on what you are trying to achieve. Eg. if you take API apart, it may be easier to scale it over multiple instances, but at first it costs you an efford to configure separate project.
If system is supposed to be single-server instance or every istance should be absolutely independed on other instances, single multi-module project will be enough - lets say a standar CMS, blog platform, even simple browser game or homepage of mobile app including API for it. But if you are building a whole universum of apps like an internal API to privide content, CRM to manage it and a couple of web pages to serve it, keeping these as separate projects will be easier to manage later.
Well for example I in my application im splitting every functionnality - for example i have model Link - it's splitted to seperate module to have nice application structure where each funtionality is seperated module. It's like less classes to load in loader. Beacause you only need models and routes from each module to load for whole app, and you load other things like librarys/controllers/helpers/services in module.
What is the best way to create a single page module for Yii2?
For example using Ember, I will have index.html and assets folder to publish.
I see two ways, one would be to just put the application under web accessible folder, it will work fine.
But what if i want to check access to the application using existing RBAC?
Another way would be to create a module and in default controller have something like
return $this->renderFile('#path/to/index.html');
And load all assets with Asset Bundle.
The problem with this approach is that i will not know the folder where assets will be loaded (it can be solved with afterCopy callback or something, but all this doesn't look nice at all).
Please advise.
Certainly it is a personal choice technique, since control RBAC is manageable level action and does not pose any problem. Once the controller is easy applicarre your organization's access control using a suitable configuration of the Access Control filter.
Alternatively, the fact of creating a module appropriately for these purposes makes it all the better organized and, precisely, modular, beyond the greater complexity in the creation of the various parts in play (module, asset, cofig / main.php) yii2 handles very well and automatically the assets and necessariio not know a priori in the name of the folder where I finish the specific assets (Yii2 find what they need).
However if this is not a 'module' with reusable application characteristics I would opt for the first solution
I am embarking on creating a Yii project that basically has a shared data model (let's say CerealStuff) with a front-end web site (call it site), admin site admin, and web service ws. I am new to the whole MVC thing and I wanted to know how I should design this project to stay consistent with Yii/MVC best practices. So far I have identified two basic options:
Create models CerealStuff at root, create three modules site, admin, and ws each with their own controllers;
Create models CerealStuff at root, create two modules admin and public with public containing controllers that handle Site and have #soap declarations to handle ws stuff.
I know that option 2 reduces the total amount of reproduced coding but it does not feel as clean quite honestly. Also I feel like maybe a modern web app should be such that even the "site" (view) uses the web service to access the database.
Tell me what to think!
I'm exposing a simple web service in my app, and I went with a separate (soap) controller.
If you follow the fat model / skinny controller paradigm, it's pretty simple to tack on a web service front end to your models.
Edit: better example of fat models: http://www.therailsway.com/2007/6/1/railsconf-recap-skinny-controllers
Read this article to see an example of MVC structured Yii project with two entrance points for front-end and back-end. Once learned this you can add another entrance point easily for ws.
As you can see all models are shared between modules. Controllers, config files and views are separate. Views can be configured as shared as well. I used this type of structure in many projects and never had any issues with extending or scaling.
As our company starts using Zend Framework as the base framework for most of our projects, we want to share some common elements across all our projects. I talk about things like:
An implementation of a model (based on doctrine2)
RBAC for the model, including user, group, role models
A xml-based templating engine for ajax backend interfaces
(you name it) ...
Basically, all things to put "zend on rails" and get going. What is the best way to package these components? I see two possibilities:
As modules
We include the necessary functions as separate modules into the modules folder.
Pro:
We can set routes and execute code, which is good for many modules (imaginary example: a paypal module needs some kind of callback url. If our module can set it up on its own, no configuration from the "project developer" is needed).
We can provide real functionality (like the user administration) out of the box
We have a bootstrap to set up autoloading and doctrine etc.
Con:
Bad place? Interferes with the users project
A little harder to share between projects (git submodules instead of classpath)
In the library folder
We put it in the library folder and point the classpath to it.
Pro:
Clean solution
Sharing across projects
Con:
Bootstrap has to be explicitly called
No direct routing or actions - everything has to be proxied through the concrete project
So, how do you solve this? Where do you put your reusable, general purpose stuff in zf?
I think you should use both approaches.
When developing "library-like" code, as in kind of "infrastructure" classes and other things that are reusable (like ZF's own components, Doctrine 2's components etc.), you can put them into the library directory. (or its own entirely separate project)
When developing actual ZF modules (like an auth module for example), then format the code around the ZF module structure.
I think by using this kind of approach you get all the benfits you listed, and pretty much none of the cons :)
As one additional idea, if you develop your architecture parts as "services", you could even keep them running as their own web service endpoints.
I have way too many modules in my application. Currently my modules are namespaced, but what I'd like to do is have a directory structure so I can get rid of this redundant and annoying namespacing.
For instance, for modules named "xModule1, xModule2, xModule3", I'd like to have a directory structure like this:
-x
-module1
-actions and templates
-module2
-actions and templates
-module3
- actions and templates
Surely the developers at symfony know that people would like to use their framework to develop large applications. So how is module organization like this done?
I've done a lot of work in Java/Spring, and because source is component scanned, you can arrange your controllers and jsp files in nicely organized hierarchies. Is this somehow possible with Symfony?
No, this is not possible with Symfony. The structure of your modules and their actions and templates is expected in a fixed file system layout and I haven't heard anything about that changing.
I've run into the same problem you're facing where a very large site ended up with 30+ modules in a single application. At first it seemed cumbersome but after dealing with it for a while I found that the single location to search for a specific module was in fact beneficial instead of having to guess through sub-structures until I got what I was after. Seeing that structure grow and grow also pushes me to respect adding new modules only when it's absolutely necessary, folding new functionality into existing modules and refactoring existing modules to work with new enhancements whenever possible.
Symfony does have auto-loading features that will work for your library folders however, allowing you to have lib/one/two/three/Object.class.php or any other structure you see fit.
If you have so many modules, you could consider to move some functionality into plugins (i.e. create your own plugins).
The benefit is that you can use this functionality also in other projects.
Or you can group your modules into applications. You can have as many applications as you want, not only backend and frontend.
I've wondered about the same thing, especially as many configuration files need to be set either at application level or individual module level. It could useful to be able to cascade configurations to a set of modules.
As mentioned above, it seems the available solutions are:
deal with lots of modules
create separate applications (which will create some wieldy duplication)
refactor your modules to be as efficient as practical (i.e. multiple controllers & views per module)