How to take care of fetching related objects of one object?
For example object project has some tags. How and when should I fetch those object? In user initialization in mapper? That would be a big overload. The best way would be to load them dynamicly when system ask user for tags, but how to do that if model does not know anything about the mapper? Or just use Doctrine and forgot all about those problems?
Im asking this in relation to PHP Zend Framework. But any technology would suffice I think for this problem.
It is difficult to answer your question because you are not referring to a specific ORM or framework. If you are looking for suggestions, I would recommend using Doctrine as the model API and Zend Framework as a stand-alone library.
If you need a full featured framework you can take a look at any of these:
Symfony2
CakePHP
Zend Framework (as a framework vs stand-alone lib)
CodeIgniter
If you choose to go with Doctrine as your ORM, you can setup the schema file to ensure objects are relationship aware, then you can make references like:
// Joins tags table by way of intermediary object_tag table providing
// a M:1, 1:M relationship
$tags = $object->getTags();
Doctrine (1.2 not sure about 2.x) does employ lazy loading pattern, where the objects are only queried when requested.
Related
I'm trying to teach myself ZF2 in conjunction with Doctrine 2. I've completed both the Album tutorial and Blog Tutorial on Zend's website successfully. Now I'm trying to go back and convert the Blog Tutorial to use Doctrine 2. I believe I've successfully setup my config for doctrine and used DI to get it inside of my controller (WriteController.php) since I am able to dump the contents of it within my action. I don't get any errors so long as I don't do anything with it.
My question is what roll does Doctrine take in the Controller -> Service -> Mapper -> Backend layered structure which was taught in the Blog tutorial? (Reference To what I mean)
Also, I'm assuming Backend is referring to my Models. Is this correct?
Would I just replace any references to /Blog/Model/Post with /Blog/Entity/Blog?
The Doctrine is the Mapper. And maybe we could say also the Service (through EntityRepository). But usually you will create your own Service Layer.
The Backend is not the entities it self. Entities in one way to map the several options of backend. As backend you can understand the several options of Relational Databases (Mysql, SqlServer, Oracle, etc) NoSql Databases (like MongoDB), file system and so on.
I didn't understand your last question. But when I use Doctrine I always create my entities in /MyModule/Entity namespace. While when I use the standart Zend/Db I always create in /MyModule/Model. I do that by standardizing matters.
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'm new to using an MVC structure, and am developing my own MVC framework for a university project. I've got a database class that I can use to send a query to the database and return me an array of objects (PHP standard object class). I then want to display a list of the objects on an index page.
My question is, should this list of standard objects really be a list of models? Or are they fine as they are?
You don't have to create separate model classes just for the sake of creating model classes because they are in the MVC pattern name. If your solution also works when you simply pass the array of PHP standard object classes to your view, you should just use that. In that case creating model classes would just be extra work for no benefit. However, if you need additional functionality besides simply outputting a list of database results, you should consider creating actual models.
You should store data in your database and manipulate this data (create,update,read and destroy) with your models. I think you should better know what is MVC and what is for. You can read a bit here
depends... One could argue that most applications are very heavy on the Model side (Fat Models is an actual pattern), therefore it will not be enough to create a few stdObjects from an array, but actually map tables to object classes, so you can add useful methods to them.
I would recommend to take a look at Doctrine and try implementing a subset of features.
I've a question related to Doctrine 2 and Zend Framework.
If you use Zend Framework without Doctrine by default you place business logic in the models. But as Doctrine 2 does have Entities where should the business logic be placed?
I first had created models where the entity manager did calls to the Entities. But when I wanted to write unit tests for my models without database calls. I needed to move the entity manager to the controllers. But I'm getting business logic in my controllers which is not good.
The code below shows a part of an controller action:
$customerAddress = $this->_model->save($values, $id);
$this->_em->persist($customerAddress);
// Update default billing address
$defaultBilling = $this->_model->saveDefaultBilling($values, $customerAddress);
if ($defaultBilling != FALSE) {
$this->_em->persist($defaultBilling);
}
// Update default shipping address
$defaultShipping = $this->_model->saveDefaultShipping($values, $customerAddress);
if ($defaultShipping != FALSE) {
$this->_em->persist($defaultShipping);
}
$this->_em->flush();
Can somebody say what's the best practice for this issue? Thx
I'm not sure there is an agreed upon best practice, but I see a lot of talk regarding Service Layers when discussing Doctrine or Zend Framework.
When I started my app with Doctrine, I tried to build as much functionality into my Entity objects as I could, but quickly realized that's almost impossible without injecting the Entity Manager, which totally breaks the idea of plain, non-persistence-aware objects that makes Doctrine 2 so nice.
If you're coming from an Active Record world, it's easy to think of your 'model' as single object that corresponds to a database table and that controllers have to talk to these objects. This is usually okay for very simple CRUD applications. But because of Doctrine's approach, doing it that way is weird and frustrating.
Instead, think of the different layers in your application. Doctrine is a layer that sits on top of the database, your Entities sit on top of Doctrine, and your Service Layer should sit on top of your Entities. That whole package is your M in MVC, and it comprises both data persistence and business logic.
I would suggest you check out this presentation on the topic.
UPDATE
I originally missed the part where you mentioned you had separate model objects making calls to the Entities. I think that would be an acceptable pattern to use. If you want to write tests without making database calls, you're probably going to want to to use a mock of the Entity Manager -- it's a dependency no matter which layer you put it in.
Here is the github skeleton project I used, it did the doctrine 2 initialisation with Zend Franework 1.11.2 in the bootstrap, nice and clean, using model for entities & model repository for business logic. Unit tests & ant build script too for you TDD developers out there.
https://github.com/eddiejaoude/Zend-Framework--Doctrine-ORM--PHPUnit--Ant--Jenkins-CI--TDD-
I have one doubt in zend framework. I need all model details from project which i have done in zend framework. Is there any possibility to get all model details in zend framework.
Please help me..
Thanks and regards,
Prasanth P
If by Model you mean you want to get the details about a DB Table, then yes. You can get this data by calling the following method from Zend_Db_Table
info() - Returns table information.
There is no method to say getAllDbTables. If you need this, you could write a custom Db Repository that knows all Db Tables and that can give you table instances and any info information you need about. This would have the additional benefit of decoupling concrete table instances from your using classes.
Keep in mind though that the M in MVC is not just the database. The M is the heart of your application. It contains application logic, domain objects, service layers, etc. The persistence layer is just one part of it.