We are developing a substantial PHP web application using the Zend framework.
At this time, the product is starting to stabilize and we are moving away from quick-and-dirty setups in order to avoid regressions. In particular, we are now working on top of a single shared database that everyone edits. We want to get rid of this ASAP.
The Zend framework does not seem to support the classic RAD (Djangoish) mechanism where you define your data models and then it creates the tables for you. So we are thinking of using an external ORM tool that will do this.
We could have our schemas and initial fixtures defined in plain SQL but this is a) verbose b) error prone c) too low level and d) problematic because we must maintain different versions for every supported database backend.
So we are thinking of using an ORM like Doctrine or Propel to define our models and create tables with their initial data using the chosen framework's dialect. The application uses the Zend tool for ORMing so consistency between both tools would have to be maintained manually, but since changes are more gradual now this doesn't seem like much of a problem.
So, far, we are evaluating Doctrine and Propel for this task. Any suggestions about other ORMs that we missed? Maybe a different approach altogether for the task at hand?
Thanks!
Gonzalo
I really love RedBean. You keep your database models in pure php and it keeps track of everything.
RedBeanPHP is an open source ORM tool
for PHP. It focuses on simplicity and
ease of use. What makes RedBean unique
is that it creates your database
schema on-the-fly. It scans your data
and adjusts the column types to fit
your object properties. If your models
are stabilized you can freeze the
database. This way RedBean is easy to
develop with but is also extremely
fast on production servers.
Since I've found this ORM, I don't use doctrine any more.
http://redbeanphp.com/
Related
I'm planning to build a single PHP web page that will contain lots of structured data in nested divs, spans, bootstrap elements etc., like:
Hardware
Notebooks
HP
Apple
Dell
Tablets
Apple
Samsung
Software
Operating Systems
Windows 10
...
The list ist really long with far more than 100 elements. The elements will change from time to time, but the structure will be the same for all elements and sub-elements.
Now, I wonder if plain HTML+CSS is the best way to code this page. As the structure of the elements is always the same, so it would probably be a good idea to use templates. However, I'm not sure if I really should set up a database and some kind of PHP framework like Slim or Laravel/Lumen in order to generate the code. After all, it's just a single page without and routing, forms, login etc. So this might be too much.
Perhaps, a templating engine like Plates could be the answer? But where should I store the data?
What would be your choice for such a use case? Single page with lots of structured data?
Any help is greatly appreciated!
Based on your subject line, I want to clarify something and then suggest a solution.
PHP Components & Composer
State of the art PHP development utilizes Composer to orchestrate component libraries. This could be in the form of a full stack framework or in the form of just a few specific component libraries that solve the problems you have.
Datastores
Your sample shows data with simple hierarchy. Certainly for ease of maintenance a datastore of some type would be helpful. A relational database or a document database will do the job. If that is what you want I'm going to suggest you use a specific ORM or at least a portion of it, and that ORM is Doctrine.
Why Doctrine? Because it supports a number of the most popular open source RDBMS, and it also allows you to use it's DBAL layer without the full ORM, if you just want to implement a few simple queries. With that said, if you have the option of using MongoDB, MongoDB collections support hierarchies very well. A great feature of Doctrine2 is that it has support for MongoDB, which differentiates it from most other PHP ORM's.
The only real reason to go to all this trouble is that you also intend to create an administration tool that will let you maintain your hierarchical data. If you don't, you could just as easily have a script that you include that has the data in PHP array form.
Templating
For templating, my suggestion is that you use Twig. As part of the Symfony components, Twig is both self contained and part of the Symfony full stack framework. It's robust and well designed, and has numerous features (although to be fair, Laravel's Blade has similar features in most cases) and includes support for ESI which could be a great feature for a relatively static page like the one you describe.
Templating in twig, vs writing PHP code to do the same, lets you focus on your markup and avoid introducing a lot of PHP code that will turn your view code into spaghetti.
Components
The important thing is that you can simply use the few components you need to support your application, and you certainly don't need either Laravel or Symfony. Since Symfony began its life as components (and was the foundation for the Laravel project in fact) I'd push you towards the Symfony components, although at the end of the day, you could also utilize parts of Laravel (Blade, Eloquent) in the same way that I'm advocating you use portions of Symfony. Symfony simply is the community and stack I prefer, and has a longer history of being used on a component basis in other projects.
Try out the new minimal Symfony4
Last but not least, the newest version of Symfony (Symfony 4) is really worth looking at for a number of reasons. It essentially is now a micro framework, that comes with the bare minimum of components. They advertise it as 70% smaller than v3.
What differentiates this release is the innovation of Symfony flex with recipes and Composer integration. It is now built to automate a lot of the things that you might otherwise have had to figure out on your own for putting these components together into an application.
Take a look at it and see if it might help you get your application built with minimal components and minimal time spent having to learn how to make things work together.
In summary, I'd suggest you consider:
Symfony Components (You might want a few more depending on your
final solution).
Doctrine2
Twig
Symfony4
Is there currently any technology that would separate storage from business logic and allow me, to easily switch from MySQL do MongoDB? (I assume I migrate the data myself, or start with an empty database after the switch).
I would like the change to be as easy as changing the configuration, the driver, and the db connection data.
I understand it is possible for PHP with Doctrine, switching between different RDBMS, but I'm interested in switching from any RDBMS to a NoSQL system.
I am focusing on PHP now - but if you know any solutions for other programming languages - I will be happy to learn about them.
I am assuming not a complex database, no transactions, no complex relations.
More background/details
I am writing a simple crawler that will visit websites, and read some data and save it to the DB. It is super simple and I might go with pdo_mysql for PHP only. I am considering an extra layer only to cover the situation in case I want to switch from MySQL to MongoDB one day - and I asking if this is even possible.
Update
I think that Laravel with its Eloquent supports MySQL out of the box, and with an extra plugin: https://github.com/jenssegers/laravel-mongodb supports MongoDB - I will check if this is truly transparent from the programmer's perspective. Unless someone has experience and knows right away?
A typical approach here is the DAO or Repository design pattern. In this pattern you provide a library which is responsible for persistence and returns business objects. The objects do not have persistence logic and get stashed in the Repository or retrieved from the repository.
This being said, that only works for business objects. The problems will come up when you want to redo reporting or the like.... Here the differences between an RDBMS and a NoSQL solution will bite you hard.
To be sure I don't know what a use case is given that "what do you want to do with your data" is a massive concern in selecting between these.
I am in the process of picking a PHP framework for a web application I am starting. I have never really used a framework in the past but with this project there is a great need.
I have been debating between the usual suspects; CakePHP, Zend Framework and Symfony. I have been going back and forth about which framework will work best for me and this project. I am leaning towards CakePHP but I am still researching.
My question is not what framework is best. I know there is no real answer to that and there are tons of posts related to this subject. My question is related to the Model and ORM. I have read a lot about ORMs being slow and I am concerned about speed. I am very comfortable writing SQL and in the past have tried to keep all of my database interactions in stored procedures.
I am looking for some feedback about using CakePHP's ORM or Doctrine with Zend or Symfony as apposed to keeping everything in stored procedures. I know stored procedures are going to be faster but what else will I loose if I do not use an ORM? I understand that an ORM will give me database abstraction but in my mind that just helps people who do not write SQL. I also know that I do not know enough about ORMs.
If anyone can give me some feedback about this and which framework might be best based on using or not using an ORM.
Thanks for any help in advance.
0) Bang for effort
The key advantage with an ORM is that you don't spend as much time dealing with the persistence layer. A pre-written ORM ( I have worked with EclipseLink) will provide a ton of things you probably won't get in custom written stored procs. I think it's worth thinking about how much time you want to spend writing your persistence layer.
1) Caching
All the major ORMs provide multi-level distributed caches. Combined with Named/Predefined queries you can get SQL queries that don't actually have to go to the database. This can give you excellent performance.
2) Abstraction
ORMs allow you to define your table layout in one location and then they manage all the painful mapping between columns/tables and objects. Some will allow you to remap column, table and schema names without changing any code at all. If you work with people who like to change things around this can really simplify things.
3) Speed
Some ORMs can have bad performance, but it really is based on how you use it. I find that you tend to end up over-querying for things. On the other hand, you get things like built-in query profilers. You can write custom SQL for queries if you find you aren't getting the performance you need.
Mark Robinson gives a great response. I'm just going to back up what he says by giving our experience with Doctrine2.
I chose to use Doctrine2 as our ORM with Zend Framework a little while back. Our project is still being developed, but choosing D2 has been a decision we've not regretted one bit. Whilst you still need to give a lot of thought to your data architecture, D2 gives you the flexibility to be able to modify that model at a later date if needs be. It allowed us to try things out quickly in the early stages and the room to grow and change later when we decided that things weren't quite right - it happens.
In relation to Mark's point about abstraction. One of the other things I love about D2 is that we're working with plain old PHP objects. Don't underestimate the power of being able to think in terms of objects - both for the people responsible for modelling the data and the developers who work with the data - it'll make your life easier, trust me. Also, having inline documentation of the ORM mapping (if you choose the docblock approach) is nice.
Right, performance. As Mark says, there are ways and means to speed things up - but there's always going to be some overhead. Whenever you introduce another software layer, there'll be some performance hit, but it's a tradeoff. For us, the tradeoff - the advantages of using the ORM vs performance - is worth it. We'd spend more time debugging code and not getting things done without the ORM.
Anyway, D2 can help you with caching for queries, results and metadata. Whilst you probably just want an array cache during development, it's great that the facility for things like APC, memcache etc. is there when you go to test and deploy. You could even develop your own if you're brave.
http://www.doctrine-project.org/docs/orm/2.0/en/reference/caching.html
Hope that helps, I've probably missed stuff, but if you have any questions just fire them in and I'll do my best.
A framework implements mainly three kinds of features :
the flow between "getting a request" and "rendering a page". That's were you put things like MVC, router, etc...
the way to manage your model and it's persistence. That's where you see acronyms like ORM, DBAL, DAO
Components. Features, often working also standalone. Like Xml parsing, i18n handling, pdf generation...
When you choose your framework, it in facts means that you choose 1). It's the thing you will certainly have to stick with, it's the flow of your application. 2) and 3) ? You can integrate those you prefer. As an example, i'm on Zend Framework with most of it's components, but use Doctrine ORM 2 and Symfony's Dependency injection. A friend of mine is on Symfony 2, uses Doctrine ORM too, but does it's pdf generation and mail management with Zend's related components.
The other thing you need to know if that currently there is a "second generation" of php frameworks/orm's, (re)written to take advantage of the new php 5.3 features, and/or to solve the general performance/coupling issues they (nearly) all had. Some of them are production ready, some are still under development :
Doctrine ORM 2 (production ready)
Symfony 2 (production ready)
CakePhp 2 (in RC 2 currently, but by the time your project is ready it should be stable)
Zend Framework 2 (still under active development, but normally not for so long)
FLOW 3 (beta2, should be ready soon too)
For the ORM part, i'll recommend using one, especially Doctrine's. #Mark and #iainp999 explained perfectly why.
ORMs are for programmers who don't "grock" SQL!
Yes ORMs make it easier (or at least require less lines of code) to write simple CRUD stuff, but when you get to more complex requirements its like trying to write SQL with a piece of wet spaghetti from ten feet away.
So stick with SQL.
Its worth looking at something like "SQLMap" which is ORM starting from the "R"elational side of the mapping (most try to map an "O"bject on to a table). This will allow you to write the SQL yourself and generate the appropriate "helper" classes to easily access the results in your program.
After working a while with Codeigniter, I am totally in love with the ActiveRecord way of writing mySQL queries. Now, when working on another non-codeigniter project I've been recommended to use an ORM to handle the DB mapping which sounds great, but after looking into Propel & Doctrine, I have become quite afraid of the additional configuration files containing the database structure, more or less.
Why does these ORM:s define the database structure and what advantage has it over an non-defined ORM like the one that's bundled with codeIgniter?
FYI, there was a thread about this a while ago. The gist of it is that ORMs (ActiveRecord is an common ORM pattern) help enable database independence and quicker access to common queries. Downside is that ORMs are "heavier" than straight SQL. For most apps, 90% of your data access is pretty standardized so ORMs help with time to market.
ORM and Active Record Pattern in PHP?
I am fond of dbstructure definition of msaccess which lets defining at once and creating the data entry forms, datatables and reports at once easily.
I have been searching for some framework which would generate the data entry forms, data tables and reports easily. I guess the only thing I need to define is complete datatable structure.
Is there any like that or better one than that?
EDIT:
well i am afraid that PHP frameworks have been limited to programmers only. I would like to extend it with some automated functions like autoform in msaccess which would generate data entry form, auto report for data listing. So that my development time would be again some less. I found doctrine nearly matching my specification but not sure as i haven't fully explored doctrine
Cake offers both "hard" (bake) and "soft" scaffolding, which should be very close to what you want. It's still only meant as a quick proof-of-concept tool and to get you up and running faster so you can concentrate on programming the business logic. It's not meant as a hands-off solution nor to be used in production.
What you seem to be looking for is a database frontend like phpMyAdmin or SQL Buddy, not a PHP framework.
Symfony provides an admin generator that builds all the forms on the fly and it will also update itself when you change your db schema. It is based on doctrine which you say you looked at so that would make things a bit easier for you.