I have developed my little own framework, which depends on some model classes. I am using the framework on different projects, but with side effect that project-related changes in the framework are not committed to one "single" framework code, but the changes lost for the other projects.
Now I want to outsource the framework code to one single place and symlink in my projects to that code. So that I am using one model in the framework I have a schema.xml for the framework. In the projects I need also schema.xml files for project-related models. In one project I need to extend generated classes of the framework model.
Is there a way to extend a schema.xml file, so that the propel_generator can generate correct sql file and model classes?
Or is there any workaround / better way for such issues?
I guess that you could use the <external-schema> element and split your schema into the "common" part and the "project specific" part (containing an <external-schema> element pointing to the "common" schema).
See Propel doc : http://www.propelorm.org/wiki/Documentation/1.5/Schema#external-schemaelement
I had a leck of understanding of the terminology "domain models". I wanted to use the models created by propel not only as domain model but also as application model. But this would be wrong.
I will use the <external-schema> feature to divide my domain model into different parts, but I need to create a "application model" layer to encapsulate the domain model from the rest of the world ;)
Related
I am developing a little application with PHP web framework Laravel v6 and MongoDB (with jenssegers moloquent) as database engine. This is my first encounter with any MVC framework. I have the following collections in my database:
allPaintingsCollection
paintingHistoriesCollection
paintingCategoriesCollection
artGalleriesCollection
paintingArtistsCollection
supervisorArtistsCollection
smPlatformsCollection
nonSmPlatformsCollection
targetSchoolsCollection
I have been following this tutorial. I have the following two questions:
Do I have to create a separate Model (separate class in a separate file) for each collection above?
Do I have to create a separate Controller (separate class in a separate file) for each collection above?
New Answer:
1. Yes, you will need to create a separate model to use the ORM. Ideally, the model should only support a single collection, doing so you can create custom logic. Remember, One Model One Collection/Table.
For Controllers, you can write it any way you like, you can use all models inside a single controller. But what I have learned so far using Laravel, you should create a single controller for each model to fully and logically support the separation of concerns.
Know the BTS:
Laravel heavily uses PHP Composer's autoloader functionality, so having multiple classes in a single file won't work.
For example, when autoloader starts, it would look for User class in \App\Models\User.php file. Having multiple classes in a single file won't help in this case.
Latest Laravel's version follow PSR-4 standard. You can have a look at it for more understanding.
For more PHP coding standards you can have a look at PSR-2 standards.
I have 2 projects accessing the same DB. One is with CodeIgniter, the other is a home made mvc framework. I'd like to use the same Model layer.
Is it possible to access Codeigniter Models from another project?
I'm not exactly sure why you would want to be accessing the same DB from two different frameworks at the same time (sounds like a recipe for disaster), but in general, I would say, "no."
What you actually want is not the model itself, You actually want the active records class located in /system/database/DB_active_rec, as that's the most common usage.
That class extends CI_DB_driver
This class accepts the config parameter for the DB(connection information).
You then want to extract the drivers themselves being used for the specific database you're working, the drivers can found at /system/database/drivers.
CI->model simply loads the DB_active_rec, that's why you need to do $this->db->insert()
I've never did so myself, But I don't see any major dependencies in the files themselves. I might have missed something though
I have to create a php project using Codeigniter and Doctrine.
I worked alot with j2ee and I would like to use the same project structure in my php project.
So here is what i'm thinking:
Controllers eg(UserController)
Services aka Models Interfaces (UserService)
Services Implementantions eg (UserServiceImpl implements UserService)
Dao Interfaces (UserDao)
Dao Interfaces implmentations eg(DoctrineUserDao)
Doctrine Entities
Views
I haven t seen implemented in php projects interfaces for services and dao design pattern is always missing. Are Interfaces and DAO redundant in php mvc projects ?
And another question: as far as I know Codeigniter loads model using the following syntax:
$this->load->model('UserServiceImpl'); which is kind of lame in my opinion, i prefer using autoloader with namespaces, is this bad ?
I've designed a few smaller systems with CodeIgniter, and now I'm designing/building a big one. I always followed the same structure (the one I'm going to describe here) and it worked for me very well so far. For my current project we tried to use Doctrine as the ORM, but in the end I decided to leave it out from the project - it was more of a burden than help.
(I may use slightly different terms for the layers, but I tried to put them in parallel with your terms wherever I could.)
The structure I use is:
Controllers (e.g. /application/controllers/UserController.php)
Data Mapper (ORM) layer (e.g. /models/tables/UserTable.php)
Domain Object layer (e.g. /models/data_models/User.php)
Layouts (e.g. /models/layouts/default.php)
Templates (views) (e.g. /application/templates/user/view-profile.php)
Responsibilities:
(2) Data Mapper layer contains all the SQLs, and all Doctrine EntityManager usages. It stores and retrieves Domain Objects.
(3) Domain Objects represent the entities (with entity metadata described in comments for Doctrine, using the Docblock Annotations format).
(1) Controllers do only the logic of calling the ORM layer, maybe do some restructuring of data or calculations.
(4) The layout layer helps me a lot with separating the quasi-static frame of the pages from the more dynamic content. See CodeIgniter and layouts? if you like the idea.
(5) Templates are basically HTML with a few PHP snippets.
All my files that contain classes contain one class per file, named the same as the filename (as per http://www.php-fig.org/psr/0/) but I don't use namespaces because I find it hard to make it work with CodeIgniter that doesn't use them.
You can load your models in autoloader, especially if you work on a small or medium-sized project and performance is not critial. I always load all my models with the autoloader in these cases. However, on a bigger project it's more worthwhile to load widely-used models in the autoloader and more specific ones in the controller constructor or the more specific ones even in the actions.
I have a question regarding a custom mvc framework. I am a little confused with how I should implement the models portion. I am thinking since doctrine entities will be my models, then I could create another folder named models in my file structure and within this model folder I will have individual files that will perform the crud functionality. The reason I am trying to do my own framework is that I plan to use dojo mvc on the front-end.
for instance my models folder would look like:
models --> users
logger
blog
and inside say users class some code my look like:
class Users{
public function getUsers(){
$users = $this->em->getRepository('entities\Users')->findAll();
echo // the data from
}
// also there will be setUsers, etc...
}
Thanks everyone
With in the MVC's Model (at least to my comprehension), the Doctrine should be dealing only with information storage and retrieval for Domain Objects.
And, depending on how you actually implement the front-end part, you might have a very thin interface (that's what views and controller provide) over the model layer, which basically just provides REST API.
Materials you might be interested in:
GUI Architectures
SOLID principles
Law of Demeter
.. added the last two, because your code bit feels a bit off.
What I have is the following db structure(tables):
lists[name,id]
list_items[title,list_id,content]
I've created the needed files and code(the MVC) needed to manage the first table(lists).
I also added the hasMany to the model class. At that point I am stuck.
What I need is a solution for managing each item (basic CRUD, I assume that complex management is just an advanced CRUD that I will find out how to do by myself).
I will be specific: since it's a content that have no place (but the admin) that it will be used by itself, should I -
create a full mvc structure for it? (can or should I implement it somehow[how?] in the lists package?
if not, how can I attach the tables? (since the use is about to be dropped in version 2)
would an element(cake concept/context) will be the appropriate way to create a view for such situation?
ANY insight will be appreciated.
If I undertant correctly, you want to create a CRUD part of this tables by yourself, without bake.
You need to write all the MVC estrucure and be carefull with the naming combention of cakephp http://cakebaker.42dh.com/2006/02/18/cakephp-conventions/
You need the model into app/models and also a a controller into app/controllers (remember naming combentions) and for each model you need a folder into /app/views.
Alfo, every, every function in your controller needs a view, even if this action doesn´t write anything to screen
I hope this was usefull.
Have you tried using Cake's bake feature? Your CRUD will be automatically created in about 2 seconds. I would also recommend you do the Blog tutorial to get a feel for scaffolding.
CakePHP is all about convention over configuration. Eg naming conventions for tables, controllers, models etc.. So much can be done automagically.