DB_DataObject does not appear to be ActiveRecord because you do not necessarily store business logic in the "table" classes. It seems more like Table Data Gateway or Row Data Gateway, but I really cannot tell. What I need is good ORM layer that we can use with DataMapper and a DomainModel. Any ideas?
Follow this link to read what DB_DO is. In a nutshell, it doesn't implement a specific pattern, it just aims to provide a common interface. The idea is to not rebuild the same basic code in each project.
As for an ORM, I'd recommend Doctrine. It implements ActiveRecord.
It sounds like what you're looking for is something like IBatis for PHP. Sadly, this doesn't yet exist. I've actually written some custom DataMapper stuff based on PDO for the current application I'm working on to achieve a persistence ignorant domain layer. It's definitely more work to develop and maintain though, so I would suggest if at all possible, go with an existing data layer implementation like Doctrine for most of your needs.
Related
I've been learning Yii2 framework for a couple of weeks now. One of its core concepts is "Fat models, thin controllers". Reading the source code of the advanced application template I found that due to this concept nearly all the logic is contained within the models.
Well, there could be no questions at all if I hadn't some experience with Spring MVC where service layer seems to be a kind of natural way to decouple application's logic from its actual data.
So the question is: can it be a good practice to implement such an enterprise-like structure in an application built with Yii2? Speaking more specifically: is it worth breaking Yii's models into Entities, DTOs and Services?
Thank you in advance!
P.S.: The question can seem to be a kind of too abstract or subjective but having little experience with Yii2 I'd like to know are there any architectural features in Yii2 that could make the above mentioned implementation be not optimal in regard to code maintenance, performance and so on?
You can actually create models that are not ActiveRecords, so they actually become your service layer, just need to extend from yii\base\Model or yii\base\Object as you see fit, and implement all the logic you need there. You can also create those models on another folder called services, so their namespace would become app\services\ModelName
Using another feature instead of built-in feature can not be a good practice for every framework.
IMO, the model part is a killer feature of yii2, so if you do not need scaffold (code generation), you can use any other php framework without model part (zf2, symfony2, micro-frameworks).
So you can use your own model architecture without any perfomance lag but you'll need to write more code to make things done and your models will be hard to support by other people that are using yii2 and therefore I recommend to use another framework which comes without model layer.
I would like to know which one of the following is the best choice for O/R mapping in PHP:
Axon
CakePHP
Doctrine
Kohana PHP
lworm
PdoMap
Propel
Rocks
Qcodo
Redbean
Sphorm
Torpor
We are going to use PHP only for Web Service implementation. We have a Java background so a framework which is inspired by Hibernate would be easier for us to use as long as it's a good, well documented and more or less easy to use O/R mapping library.
Thank you!
The problem with this question is that it is hard to tell what is the best choice for your specific task and environment. Furthermore, a full comparison would require in-depth knowledge of all the alternatives.
As for Doctrine you'll be able to find a good piece of documentation. And it is fairly easy to get going.
Like Jensgram already notes, it is hard to tell which option suites your needs.
That said, I have experience with Kohanaphp and it's integrated ORM. I must say it works perfect, but it has limited functionality if you compare it to Doctrine2. If you need advanced options like inheritance mapping and proxy classes Doctrine is the way to go. Like Doctrine 2 introduction says:
Object relational mapper (ORM) for PHP
that sits on top of a powerful
database abstraction layer (DBAL). One
of its key features is the option to
write database queries in a
proprietary object oriented SQL
dialect called Doctrine Query Language
(DQL), inspired by Hibernates HQL.
This provides developers with a
powerful alternative to SQL that
maintains flexibility without
requiring unnecessary code
duplication.
As it says, it is inspired on Hibernate HQL. I don't have experience with the other options you mention, so I can't say anything usefull about those.
I used to write the data access functionalities in model itself. Now I want to separate data access from business logic. I am using codeigniter as framework.
It seems that one way of doing it is use ORM, but it will have a performance penalty I guess.
are there any general best practices?
Have a look at POEAA's Data Source Architectural Patterns:
Table Data Gateway
Row Data Gateway
Active Record
Data Mapper
CodeIgniter claims to use ActiveRecord, but it doesnt. It's more like a rudimentary QueryObject. To truly separate your DAO from your Domain objects, you have to use a DataMapper. Depending on the complexity of your mapping needs you can build one yourself or use an ORM. Ironicaly, the majority of ORMs in the PHP World are based on ActiveRecord, which is pretty ill-suited for ORM. Doctrine 2 is the only I know that uses a DataMapper approach.
An ORM will always come with a performance penalty (and it can be a serious one). However, you should not rule out an ORM just because of that. Handcrafting an efficient DataMapper in a high impedance mismatch scenario can be tedious and difficult work. Again, see POEAA for a list of common Object-Relational patterns.
There seems to a DataMapper implementation for CodeIgniter with Overzealous DMZ. I have never worked with it and cannot say anything about it. It just came up after a quick google, so I thought I add it here.
I've currently got a site that depends on an Active Record pattern using the Doctrine ORM in PHP. I'm generally a fan of this approach - it's very straightforward and works well for managing for simple CRUD apps. But as this site grows, I think my need for more robust domain functionality will grow as well. I was wondering what other kinds of data design patterns work well in conjunction with an ORM.
My basic problem right now is that Doctrine seems to work best as a fancy querying language, so my models are littered with methods like:
function getBySomeClassfication($classification)
{
return Doctrine_Query::create()
->select('stuff')
->from('ModelClass')
->where('something = ?', $classification)
->execute();
}
or if I want to access a model class directly:
Doctrine::getTable('ModelClass')->findAll();
This means I end up working with Doctrine's object wrappers instead of directly on my domain objects. I feel like all this should exist at a lower level of abstraction.
I'm just not quite sure what the best approach is. I feel like the ORM is an excellent layer for querying single tables and dealing with relationships. But I'd like to have more flexibility in creating domain objects that work across multiple models/tables.
I've read up on using the Repository pattern, but still have a few hesitations:
I don't want to just create a pointless layer of abstraction that simply bubbles up the original problem.
I don't want to re-create or render useless the whole point of using an Active Record ORM.
Any thoughts or suggestions?
You need to work with the object wrappers (Data Access Objects) at some point and at some point your calls will be implementation (here Doctrine-) specific. It mainly depends on your current architecture on how many layers you want to put in between, but I would say - as less as possible. Is there any specific problem you have that Doctrine doesn't solve?
I sometimes don't see the point in having to deal with database specifics (e.g. one Domain Entity spreading over several tables) at all when using the ORM as a tool for (from scratch) Object Oriented Domain Model development.
I recently answered a more Java specific question here, but maybe it helps you, too for the architecture idea.
You might have a look at the Zend Framework ORM implementation(if you haven't already) where it is also possible to define relationships across multiple tables.
I hope that helps.
I'm building an app in PHP and I'm using the data mapper pattern for my DB access. I was considering using the Observer pattern to have all my mappers observe the entities they create, so that they can automatically save any changes back to the database without me having to parse them back manually.
I was just wondering if this was a good idea, or if it's bad practice etc.?
I'm typically working with a few objects that are linked together in a hierarchy, and at the moment having to parse each object to it's mapper manually, which is fairly tedious, so just trying to come up with a better solution.
Thanks,
Jack
Definitely sounds like a good idea to me. What you're doing is similar to the Unit Of Work pattern intended to keep track of the changes you've made to mapped objects and commit (usually as a single transaction) once you're done.
I believe that projects like Outlet and Repose provide this for you in PHP as well as alleviating some of the mapping pain, but I haven't personally used them.
As an aside, it sounds like your object hierarchies may benefit from being viewed as Aggregates if you wish to go down the Domain Driven Design path and benefit from the clean isolation it brings.
--
Edit: it also looks like eZ Components has a fairly full featured PHP ORM solution, and Doctrine 2.0 is shaping up this way too.
--
Edit 2: I wouldn't look at Propel or Creole for the problem you are discussing. Creole is not an ORM, but more of a DB abstraction layer akin to PDO - and the project is now officially "Dead". Propel uses the ActiveRecord pattern, not the DataMapper pattern, so your domain objects end up with a lot more persistence responsibility and AFAIK it does not include a Unit Of Work facility.
If you are looking into ORM's check out Propel and Creole.