Eloquent vs doctrine

Why are you looking into doctorine and not jumping right into Eloquent? I consider Eloquent to be the biggest strength of laravel so I am not sure why you are looking into using another orm!

thank you @unitedworx . from first time I started to learn Eloquent I found it the easiest ORM for PHP .

Eloquent have many futures like relationships and polymorphic relations . but all this easy things means there is many things process back there like the queries numbers ? and this means it is bad for performance (maybe) .

@unitedworx : It depends. Eloquent is the biggest strengh of Laravel and yet its usage can become problematic if you're beggining to write bigger apps with SOLID principles in mind (won't develop on it, as the subject has been discussed many times already). But it's not specific to Eloquent it's the case with any implementation of the Active Record pattern.

@alnour_altegani : I suggest you to read this article : http://culttt.com/2014/07/07/doctrine-2-different-eloquent/

@RemiC thank you for the link . by the way is doctrine 2 support polymorphic relationships ?

Unless you're making an app that is going to serve 1000's of concurrent connections, I wouldn't worry about performance. Long as your code and relations are good and clean, it will be fast.

@RemiC

From the link you posted...This sums it up pretty well

"Of course, for other types of applications, using Doctrine 2 is going to be massively overkill.

I think you should be pragmatic in your decision when it comes to looking at what ORM to use. Whilst Doctrine 2 is great, there really is no need to add unneeded complexity."

The thing you see many people concerned with when starting to use an ORM such as eloquent is the number of queries their app will generate!

They waste a lot of time trying to reduce them failing to realise that the gain is very little and that their db is already caching queries or doing a lot of things to speed things up.

It's slow queries you need to be concerned about really to aid performance rather than the no of queries your app generates.

@unitedworx Like having indexes etc etc, I agree.

thank you @unitedworx and @bashy for reply .

first performance is issue for the new world where any thing need to be done in some speed . in the last few days I searched in the internet to read about Laravel performance and how to solve the performance issues .

I started to test :

Laravel without optimized autoloading boot in 152ms

Laravel with optimized autoloading and remove the

 ClassLoader::addDirectories(array(

 app_path().'/commands',
 app_path().'/controllers',
 app_path().'/models',
 app_path().'/database/seeds',
 app_path().'/database/migrations',

 ));

because i use composer autoload for this things

Laravel boot in 32ms

you see one request and the framework need to boot in 32ms `this without any SQL queries or concurrent requests or/and blade templates compiling you see what i am talking about ? ( i know Laravel is great framework and offers alot of futures . but if i want better performance with good framework I need to find any thing that slows my application to reduce ) .

the other thing .I need to know if doctrine 2 offers additional futures than eloquent without any performance hit .

I started all this doctrine thing because I started to build EIS and ERP with Laravel as framework of choice . and this systems need very good db ORM and very good architecture because they are very complex applications .

if any one have any suggestion about this tell me .

Of course there's ways to speed it up but do you need it that badly?

yes . do you have any tips for me to speed my applications ?

No

You can use HHVM, It seems that Laravel and Doctrine2 are 100% supported by HHVM, check this out: http://hhvm.com/frameworks/

thank you @sahibalejandro . but i use my company server and they are not like hhvm

Do you have an app ready and working and is performing badly? If not anything you look into now in regards to performance is more or less premature optimisation.

It seems that these days the problem is not the back end but the front end with large libraries like bootstrap or jquery you better of loading them through a CDN or making sure you css/js are loaded in parallel or merged in less files! Also many times you can save a lot of loading time if you look after you images property! I am sure you can save more than just 100ms by compressing an 200 kb image to 20 kb! Or merging 50 little images into a single sprite!

@unitedworx : Yes I think the article from culttt sums it up pretty well. I think it's worth getting a look into doctrine just to know when it's worth using a data mapper against an active record ORM.

@alnou : Afaik doctrine supports polymorphic relations. If you're building an ERP this I would definitely go this way, as you're likely to have a lot of business logic inside your domain objects.

If you're worried about your database query performance, you can go ORM less and use the Query Builder instead. In fact that's what Taylor Otwell suggested in the last podcast. And as @unitedworx pointed out, there are so many other factors that may slow down your app that you shouldn't worry too much about this. Again, caching db queries can help.

first thank you very much @unitedworx as you said the front end components like css files and js and large images .

@RemiC as pointed out . i need orm that can help me separate my application logic form db persistence layer .

@RemiC I have another question: how to implement polymorphic relations in doctrine ?

Sorry I'm not a doctrine expert at all. Used it once, didn't like it to be honnest (too much verbose and the use of annotations or config file are not for me )

doctrine 2 or 1 ?

Doctrine 2

"With Doctrine 2 you can't interact with database by using the entity User. You'll have to use Entity Manager and repositories. This does create less overhead since your entities aren't extending the whole Eloquent model class. Which can dramatically slow down your application a lot if you're working with thousands or millions of records." quoted from https://github.com/mitchellvanw/laravel-doctrine

The preference in Eloquent over Doctrine simply must finish when you come to big sets of results. Eloquent is Active Record and I know its performance sucks (tested on db that had about 100,000 records so in real world its not that much) and I know it from: Yii framework [at least Yii 1], Entity framework (in c#) so I decided that If I want to do anything with laravel it must be doctrine.

I'm writing this to make anyone who wants to make a large scale app with a lot of data aware that Eloquent comes at high price.

@RemiC as pointed out . i need orm that can help me separate my application logic form db persistence layer .

I understand this is very old thread but I see I can add value here.

For simpler applications you would happily use the Repository pattern to encapsulate all the persistence details implemented with Laravel's QueryBuilder and reap speed improvement low hanging here.

See another article from culttt from the same author on Repositories with Laravel Eloquent (the latter you might replace with QueryBuilder).

The Repository pattern overview.

And better late then never Martin Fowler's PoEAA p.322 - 327. Much better early though.