Why use Doctrine instead of CakePHP's standard database ORM? - cakephp

I've about to start work on a new web project using CakePHP 2.2, having mostly worked with Zend Framework 1 previously.
On first look, I really like the way CakePHP handles models and the underlying database tables, especially with regard to getting one-to-many and many-to-many relationships setup quickly with the minimum of fuss. It seems, quite frankly, a breath of fresh air compared to how I used to do things in Zend Framework.
However, over the last few years whilst using Zend Framework, I had looked at using Doctrine to provide the model relationships that ZF was rather clumsy at doing. Doctrine looked to me to be very powerful and flexible.
So now I am wondering, before I get too deep into my new CakePHP project, should I still consider using Doctrine with my new choice of framework? What advantages and disadvantages does Doctrine bring to the table (no pun intended!) compared to CakePHP's built-in ORM and database functionality?

CakePHP works best if used as a whole. In your specific case though you can use Doctrine instead of Cake's ORM if you like but you will lose lot of features of cake. For eg. the FormHelper does lot of things "magically" like guessing proper input type for fields etc. using the model's schema, automatically showing error message below appropriate fields in forms when validation fails, etc.
As you commented you don't have much experience with Doctrine either so I would suggest sticking to CakePHP's ORM and look for option only if you find it inadequate for your needs.

If you have already worked with Doctrine and CakePHP's ORM, you can decide based on the main reasons to change:
What will give you more productivity?
What will give you more maintainability?
What will give you less learning curve?
Personally, I would choose Doctrine, based on the fact that it is really specific to one problem.

Related

Database first ORM

I am currently about to start out on a project to convert a legacy access front end application using MSSQL backend database to WPF using the MVVM pattern.
The database has around 300 tables so it will need to use and ORM tool to generate the POCO classes using database first driven design.
I have recently receiving some mentoring for the project and nHibernate has been recommended as the ORM over Entity.
Looking to find out your recommendations and whether we should be looking to Entity or another ORM as opposed to what is possibly just the one that the mentor has experience using?
Thanks in advance,
I'm using NHibernate everywhere. On .NET Core, on .NET Framework, since 2009. Only some projects that are not permitted use of NH i've used EF or other orm or some like this (Linq for SQL or DAAB stuff).
NHibernate provide more control, more configuration spots and more features instead EF. It's my recomendation in all scenarios that be use a ORM. Dapper solve some questions too.
But if i have NH i don't need Dapper because we have some types of operate with database.
More options, more responsability. NHibernate is more complex. Needs a deep drive into your complexity to understand how give best performance and approach to solve any kind of database interaction. Do you do more, but you must know to do.

Should i implement view model for fast querying?

I am currently referring to a code sample in this website.
However i saw that he used both views and modelview. Then, i've come across a blog that stated among the 10 do's and don'ts for faster SQL queries, don’t use ORMs (object-relational mappers) when i searched for ORM code samples, it seemed like entity framework. So, is this a wise example to follow? Or should i just stick to simple queries? Because, the thing is, in my project, a function has to query multiple tables.
Should i stick to code-first but implement conventional querying? Or is it alright to follow the website i showed?
ADDED
Is this tutorial following 'best practices'? I found this when i searched for DTO tutorials. I was wondering since its concept looked similar to AngularJs, should i implement either one of them or could i implement both together?

Data Access in ASP.NET MVC 3

What's the recommended way of creating a Data Access layer in real-life ASP.NET MVC applications? Is it EF? Ef Code First? NHibernate? Any other idea?
Thank you & regards
There is no recommend way.
I prefer EF Code First for doing this because
the Sourcecode is very clean and easy to read
It is easy to simple change the connectionstring and generate a new database if not already exists
easy to migrate your Database if your Model has changed (no need to recreate the Database) using EntityFramework.SqlMigrations
if your Database already exists you can use the Entity Framework Power Tools to generate the Models and Database context from your existing Database
It all depends of your need:
NHibernate is a more mature ORM with a big community
Entity Framework is now getting very well supported and you can find also great information (check Julie Lerman blog)
Both support code generation from database.
Code first: allows you to create your database schema from your domain models. This is great if you don't want to bother with database. NHibernate can do it also.
To help you decide which way to use Entity Framework
Source
There are many other great ORM:
Subsonic
Stackoverflow's ORM Dapper if performance is an important criteria there is a small benchmark on the site
If you're partial to the MSFT tooling and wanting to be "modern", then EF Code First is probably the place to start. One example worth perusing: https://github.com/NuGet/NuGetGallery .
I like to use Model First because it allows me the most freedom to design and implement in my opinion. It also makes it very easy to change the database design.
There is none, stackoverflow is full of people who have gone down the various routes, so you can get help no matter which choice you make.
Best advice, try doing a few small exploratory webs using a couple of approaches which seem to stand out.
The MVC gurus (the people who wrote MVC) at MS all seem to use Entity Framework at the moment. having said that you can use any ORM (or really any data access tech you want) as MVC doesnt actually specify anything at all about the way you access data
Try LINQ, most MVC products I see make use of LINQ.

symfony vs cakephp [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is conceptually the difference between symfony and cakephp?
Just to balance out this thread, this is why I like symfony:
uses PHP5
it runs some really big sites like Yahoo! Answers, delicious, and Daily Motion.
good documentation. the jobeet tutorial on the website is awesome. walks you straight through all of the features, and after you are done you feel like you can build anything.
is highly modular; many of the symfony components work on their own.
allows you to choose either Propel or Doctrine as your ORM. Doctrine is really great and easy to use.
you can define your models with YAML or in PHP, its up to you. Some people don't like configuration files, and you can really limit their use if you want to steer clear of YAML.
the updated symfony cli (as of 1.2) is awesome. I agree with abales, before this version it was a little wonky, but now it is very well documented and follows a predictable format.
there are a lot, and i mean a lot, of similarities with ruby on rails, except that of course PHP isn't quite as pretty or flexible as Ruby(!). But, if you talk to a cake developer, they will probably say the opposite :)
the symfony admin generator, which is a step up from CRUD (which also exists in symfony), is a huge time saver. Using your data model it will generate customizable admin interfaces complete with list views (index), create, and edit pages. It's not like basic crud where it generates the source and you go in and modify it... You actually can define how each field looks, which fields you want to include, what additional actions you can perform on each object, and so on.
Conceptually, I'd say the difference is this:
CakePHP has a smaller learning curve. If you have never used a MVC framework, Cake will be easier to pick up and run with in a short amount of time.
Symfony feels bit "bigger," not to say that it is slow, but that there is a lot of code back there that will let you do a lot of really advanced things when you need to.
The best advice I can give is to quickly try to set up a your own simple data model in both, and experiment with some basic interfaces, and just see which fits your own coding style the best. I think both frameworks have very active and passionate user communities and you won't regret your decision either way.
CakePHP philosophy is similar to Ruby on Rails.
CakePHP is better for medium projects.
CakePHP is faster to learn.
CakePHP is lighter than symfony.
CakePHP's Database Interaction uses CRUD.
CakePHP uses the test system PHPUnit.
Is interesting in CakePHP Bake and scaffolding.
Symfony's philosophy is each version is different.
Symfony's is slower to learn.
Symfony's is best for large projects.
Symfony's Database Interaction uses Doctrine.
Symfony's uses the test system PHPUnit.
Is interesting in Symfony's Bundles and templates.
A big difference is in how models are created: CakePHP models are written in PHP, and Symfony models are written in YAML and powered by Propel. CakePHP's approach is more similar to ROR's ActiveRecord (although it isn't exactly an AR implementation). CakePHP, in general, is more rails-esque.
CakePHP's documentation and tools, in my opinion, have a wider target audience and the syntax and helpers are easier, but thy have yet to embrace PHP5 as their exclusive target (to autoloading isn't really there). In general, I prefer CakePHP's approach because it sort of follows an established standard, and I applaude it's organization. I'd also recommend Kohana for it's PHP5 goodness.
There's another post on stack overflow about this question, although its a bit different in focus.
Edit: I revisted Symfony to find the reasons I said 'no' and came up with these — your opinions and mileage may vary:
CakePHP also offers dead simple scaffolding and easy to understand CLI tools. Symfony's CLI syntax is a bit wonky to me, and 'CRUD' in Symfony just isn't the same. Combine that with Symfony's (awkard) action syntax and throw in Symfony's poorly designed (and challenging to understand) website, and preference for 3rd-party paid documentation (books on Amazon) and you have more ticks in the cons column.
Some of the claims about CakePHP and limitations above simply isn't true. The query is possible. You just have to know how to make it. The "automagic" of CakePHP is SUPER nice so you can hit the ground running FAST. It is BY FAR the FASTEST framework to development (hence why it's so closely modelled after RoR which obviously was a big success and buzz). There are more advanced behaviors to get data returned differently and make some of those more complex queries with a few short method calls and array parameters specified.
However. As far as I can tell, no other framework has as many "automagic" methods and classes. Cake takes the most common of tasks and provides an easy way to get it done. If you're really clever, you'll do most of your coding at the model level and make use of the app_model and app_controller file and have an extremely efficient application.
The console is great and always expanding. The community is truly amazing and there are many many contributions to help you get things rolling even faster. You can literally architect and then move "pieces" into place to build an app very quickly because most of what you'll need is available. You do not get that with any other framework. You have to spend a LOT more time coding usually.
Lastly. While the documentation was lagging, it is much better now and while Cake also got some harsh reviews during this lack of documentation and version 1.1 period...It was STILL good, just severely overlooked. With 1.2 and now Cake2 and Cake3 on the horizon...You're going to see a lot of opinions changing.
I have used CakePHP since 1.1. I'm a firm believer in it. I have used it for huge corporate sites. That receive millions and millions of hits per day...We're out of the realm of things like WordPress and Drupal for solutions. When you get to that level for a CMS type site, I am super glad to have CakePHP on it. Likewise, Symfony and CodeIgniter will help you with the scaling. I can't say anything bad about either of those frameworks either. I can only say that you will spend less time coding and find a larger community (and a super friendly IRC channel) with CakePHP.
I'm going through and documenting some of my responses to the above comments about CakePHP and some of it's (in some cases rightly) perceived faults.
Big websites are run using CakePHP, some being Mozilla Addons, Scratch by MIT, and Hot Scripts. There is a bigger list right at the bottom of the CakePHP website (http://cakephp.org). Regardless, any good developer should be able to build a scalable website using a framework as long as the framework isn't completely silly (CakePHP isn't too silly :D ).
It is true that there isn't one very good (free) CakePHP tutorial that goes through every feature of the framework, but the documentation is extremely well laid out and verbose. Anything that isn't clear can be cleared up through the Google Group and on IRC, and we welcome any and all changes/corrections to the documentation. Documentation is not just a core developer issue, as many things are application specific and people come up with interesting tips and tricks, and so thusly everyone is invited to contribute (Not just comment!). Of course it is all moderated, so most of the cruft/spam is not added.
The code is modular in that you can add in new code that supercedes core functionality. Much of the code is simply PHP classes. It is true that writing such functionality may be a burden, and I have not tried using alternate classes as fillins. Yes, it does not handle other ORMs, so you are stuck with the default, but this should be fixed in Cake3, which will be able to mix and match any other PHP classes at will (that includes Propel and Doctrine support).
The CLI is very good, and it is easy to extend for App-specific support. One example is that I recently developed a shell plugin that would automatically install any other CakePHP plugin that I have indexed from github. Took about 5 hours to build something extremely usable and flexible. I'm sure such functionality exists for Symfony, and it DOES exist for RoR :)
As for being Rails-like, it is and it isn't. Many things are similar, they are MVC frameworks after all, and CakePHP goes for the "Conventions vs Configuration" approach. PHP4 support mucks with a nicer syntax, which Symfony doubtless has because of PHP5-only support, but it is still extremely usable and intuitive. The framework does not provide EVERY feature of Rails out of the box as it isn't a straight clone. CakePHP is a framework, not a library (hi Zend), so it won't provide everything out of the box.
Generation of views is, I agree, a bit wonky in CakePHP. It is being greatly enhanced in CakePHP 1.3 and 2.0. It will support custom templates for each and every Model, View and Controller (as opposed to just a type of view as it does now). Also, there exists a set of shell tasks on github by a user going by neilcrookes that auto-bakes only certain types of views (including only admin views) which can be used in combination with custom templates to produce exactly what you want. CSS styling also helps :) but this is definitely something that can be improved.
CakePHP takes many varied parameters in it's Model::find methods, although in certain cases it may be useful to use raw SQL queries. The Model::find() method is very flexible and has not failed me insofar as creating complex finds. I suppose that is related to being comfortable with the ORM, which inevitably always takes time.
Form validation should logically be in the model layer, as that is where any action related to the database is being performed. You can specify alternate validation in a specific view I believe, or swap validations (there is a behavior for this but it wouldn't be hard to do so without it).
Multidimensional arrays are a bit silly, but you'd still likely have multidimensional objects. PHP4 had a broken Object Model and so that is why CakePHP does not use objects. This is being corrected in a future version of CakePHP (as I pointed out above in a previous comment), but it is useful to have a framework that supports PHP4 in some cases. Again, YMMV and I agree that full PHP5 will be a great boon, both in speed of the application and of development.
Databases can be swapped out at will. CakePHP does not allow functionality that is inherent in only one type of DB (hence the dropped support of ENUMs that are only in MySQL), so that the ORM is always supported and can always build valid queries. You can have multiple databases in an application, one per each Model if you wanted, and can swap them at will or even not use a database at all for a specific model. So no, it is not tied to a specific database.
In the end, your choice is your own, and I wholeheartedly suggest looking into both and reading through the documentation, checking out the Groups, IRC channels, blogs and any forums for both and seeing which framework suits your development style the best. Reader beware, I'm a CakePHP developer so my post has some bias.
Further to the existing answers, you should try both if possible. I use both quite a bit, and over some time, have come to prefer symfony.
but I'm fairly convinced that its not because one or other is better, but because symfony happens to suit the way my mind works better, its closer to what I do when I write software outside a framework, so feels more intuitive. I expect that others may find their mind fits the paradigm of another framework.
Having said that, I do think that cakephp's objects are a weakness, through the use of arrays rather than objects. (This is something that periodically develops into an intense hatred inside me whenever I need to do something that it makes hard ... ! ) They could do exactly the same, but return objects rather than arrays to represent data, and I think most of the issues I have would go away - you'd be able to add extra functionality into the data objects to achieve the things I want to do, rather than writing functions in the existing model class and passing them an array.
The model layer of CakePHP is a mess. Try doing simple things like a many-to-many relationship between a Category and an Item object and then retrieve all the Items in a Category that have a specific property set.
Like:
SELECT items.* FROM items, categories, item_categories WHERE item.available=1 AND category.id=1 AND item_categories.category_id = category.id
Something so trivial is not possible in one statement in cake with the find() method of a model.
There is also no way in the core API to add a single many-to-many relationship as in one item to the item_category table above. There are a couple solutions online including a behavior that someone posted in the bakery (http://bakery.cakephp.org/articles/view/add-delete-habtm-behavior), but that's just stuff that any good ORM framework like Propel, Torque(Java), Hibernate(Java), SQLObject(Python), SQLAlchemy(Python) support right out of the box. Basically you're either going to have to write a lot of PHP code to add those missing features or use raw SQL queries but the main purpose of a framework is to avoid doing those things so that you can focus on the application that you're writing so you're not really gaining much with CakePHP.
There are a bunch of other problems and they all really have to do with the model layer including the form validation being tied into the model layer, having to deal with messy multidimensional arrays, having to use raw sql and tying your app to a specific database.
I would say use symfony. It's a bigger framework might take a few days longer to learn but it will be well worth it. I was going to use CakePHP for a project that I am working on, after running to too many of those types of issues I switched to symfony and it's been smooth sailing.
One difference more is: Symfony separated to 3 environments: Development, Production and Testing - CakePHP can not!
It's easy to develop and test product at same time
Cake 2.0 nicely autoloads most of the classes you need, whereas I found in Symfony 2 that every class had to have numerous imports at the top of the script. Attempting to memorize all those imports is near-impossible, so you always need a reference handy.
eg. Symfony 2 controller code...
namespace Acme\HelloBundle\Controller;
use Symfony\Component\HttpFoundation\Response;
// bunch of other imports accumulate here...
class HelloController {
...
Argh, yuck. While that may be good OO technique for the purists, it lengthens development time (bye bye RAD). At least with Cake I can code most of the simple stuff quickly from memory now.

Creating web forms from a database schema

I'm wondering if there are any applications, preferably freeware, that can take a database configuration, and, with as little hassle as possible, create web forms for inserting data easily.
I'm finding it hard to express exactly what it is I'm after. Maybe I can talk a bit about what I need.
I have a configuration database that, at least usually, contains "the truth" about the servers in our system. It contains stuff like zone names, hostnames, different configuration items, etc, over multiple tables. Right now we're using simple INSERTs directly when adding new servers or other stuff, handling the keys and IDs ourselves. The crux is, they don't want us to develop a simple web form thingy to handle this, instead they want a tool that can generate the web form thingy. Did that make sense?
I'm not sure if anything like this exists or is reliable, but, I thought that if anyone knew, it's this community. Thanks!
As many have already stated, it depends on what technology you're working with:
.Net 3.5 - Dynamic Data or Subsonic's Scaffolding control
.Net 2.0 - Subsonic's Scaffolding control
PHP - CakePHP
Ruby - Rail's Scaffolding component
"with as little hassle as possible"
have you checked things like PHP/MySQL Web Database Application Code Generator 10.02 ?
or phpmyedit ?
seems to me that what everybody else proposed so far requires a fair amount of coding...
Also, have a look at phprunner. It is not free, but looking at the screenshots, it seems to fit your requirements.
ASP.NET has Dynamic Data, that I think fits your description.
There's also SubSonic. Both are free and open source.
Tried Dynamic Data?
Besides ASP.NET dynamic data, you could also have a look at SubSonic
With PHP, if you have the ability to name the tables and columns as you see fit, you could try CakePHP framework, and specifically the scaffolding feature. With scaffolding turned on, the code will create CRUD forms from the schema for you.
Here's the link for learning about SubSonic & Scaffolding http://www.subsonicproject.com/web-forms-controls/the-scaffold/
, enjoy ;)
One more link from the SubSonic forums http://monk.thelonio.us/post/Scaffold-Enhancements-in-SubSonic-21.aspx
You can try Adminer Editor
Adminer Editor is both easy-to-use and user-friendly database editing tool written in PHP. It is suitable for common users, as it provides high-level data manipulation.

Resources