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.
Related
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.
The Problem: Object models built using an ORM often need to perform multiple queries to perform a single action. For example a "get" action may pull information from multiple tables, particularly when you have a nested object structure. On complicated requests these queries can add up and your database will start blocking long before it would if you were manually writing SQL.
The Question: Where do you load balance the ORM to cut down on the number of queries that need to be made, and more importantly why did you choose this approach? Do you have separate models to load data dependent on context, or do you specify which data should load in the controller? Or something else?
ORM is really there for a good reason -- to speed up your development.
If performance becomes an issue for me, I'd rather implement some caching mechanisms instead of taking a step back and hard-coding SQL.
I recommend using the Domain Model pattern, to provide an interface to data data in an OO-friendly way. As part of the implementation of persistence within your Domain Model classes, it's appropriate to use a mix of ORM and SQL.
For instance, you'll have some simple queries against a single table. Use a convenient ActiveRecord pattern for this. But as you describe, you'll also typically need some complex queries against multiple tables for more complex related data. ActiveRecord is a clumsy solution in this case, so use plain SQL. It's the best tool when you need a complex query with relational operators like JOIN or GROUP BY.
#pestaa mentions caching which is another good tool. Here's another one you can consider: Identity Map. The point is that you should learn multiple tools, and think about which one is the best in any given situation.
Trying to use only one pattern for every situation is like driving your car everywhere in first gear.
A lot of it depends on the ORM, its philosophy and features. But assuming you've got a good set of model classes between your ORM and the rest of your application, you can do the following:
Provide methods in your models that provide the right amount of depth for most cases. If your ORM doesn't allow you to specify things efficiently, consider a different ORM (if you have that luxury)
Plan and implement caching. Since we're talking in a data-centric context, this means writing/leveraging data caching in your model.
Have a plan to split reads from writes. Either in your model or ORM configuration. Especially if reads are your bottleneck, using some replication to create a gang of read-only slaves can be immensely useful. However, if you don't plan for it, you can easily design yourself into a position where it's a pain.
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.
Recently thanks to rails' popularity, many people start using activerecord as model. however, before I heard of rails (my peer group was not a fan of open source stuff, we were taught in a .NET school...) and while I was doing my final year project, i found this definition for a model
The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model.
it doesn't say the model should represent one table as what activerecord does. And normally within a transaction, one may have to query a few unrelated tables and then manipulate data from different tables... so if activerecord is used as model, then either one would have to cram all the logic code into the controller (which is kinda popular in some php frameworks) that makes it difficult to test or hack the activerecord model so that it performs database operation on not only the table it maps to, but also other related tables as well...
so, what is so great about abusing (IMHO) activerecord as the model in a MVC architectural pattern?
Martin Fowler described this pattern in Patterns of Enterprise Application Architecture together with two other patterns or architectures. These patterns are good for different situations and different amounts of complexity.
If you want to so only simple stuff you can use Transaction Script. This is an architecture you saw in lot's of old ASP and PHP pages where a single script contained the business logic, data-access logic and presentation logic. This falls apart fast when things get more complicated.
The next thing you can do is add some separation between presentation and model. This is activerecord. The model is still tied to the database but you've a bit more flexibility because you can reuse your model/dataccess between views/pages/whatever. It's not as flexible as it could be but depending on your data-access solution it can be flexible enough. Frameworks like CSLA in .Net have a lot of aspects from this patterm (I think Entity Framework looks a bit too much like this too). It can still handle a lot of complexity without becoming unmaintainable.
The next step is separating your data-access layer and your model. This usually requires a good OR mapper or a lot of work. So not everyone wants to go this way. Lot's of methodologies like domain driven design perscribe this approach.
So it's all a matter of context. What do you need and what is the best solution. I even still use transaction-script sometimes for simple single use code.
I've said many times that using Active Record (or ORM which is almost the same) as Business Models is not a good idea. Let me explain:
The fact that PHP is Open Source, Free (and all that long story...) provides it with a vast community of developers pouring code into forums, sites like GitHub, Google code and so on. You might see this as a good thing, but sometimes it tends not to be "so good". For instance, suppose you are facing a project and you wish to use a ORM framework for facing your problem written in PHP, well... you'll have a lot of options to choose for:
Doctrine
Propel
QCodo
Torpor
RedBean
And the list goes on and on. New projects are created regularly. So imagine that you've built a full blown framework and even a source code generator based on that framework. But you didn't placed business classes because, after all, "why writing the same classes again?". Time goes by and a new ORM framework is released and you want to switch to the new ORM, but you'll have to modify almost every client application using direct reference to your data model.
Bottom line, Active Record and ORM are meant to be in the Data Layer of your application, if you mix them with your Presentation Layer, you can experience problems like this example I've just laid.
Hear #Mendelt's wise words: Read Martin Fowler. He's put many books and articles on OO design and published some good material on the subject. Also, you might want to look into Anti-Patterns, more specifically into Vendor Lock In, which is what happens when we make our application dependent on 3rd party tools. Finally, I wrote this blog post speaking about the same issue, so if you want to, check it out.
Hope my answer has been of any use.
The great thing about using the Rails ActiveRecord as a model in MVC is that it gives you an automatic ORM (Object Relational Mapper) and easy way to create associations between models. As you have pointed out, MVC can sometimes be lacking.
Therefore, for some complex transaction involving many models, I'd suggest to use a Presenter in between your controller and your models (Rails Presenter Pattern). The Presenter would aggregate your models and transactional logic and would remain easily testable. You definitely want to strive to keep all of your business logic in your models or presenters, and out of your controllers (Skinny Controller, Fat Model).
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.