Maintaining database views in mysql is sometimes cumbersome. When you change a referred table you have to alter the table and there is no clean way to do that in migrations (DB::unprepared()). I guess using query scopes in models is more maintainable. Isn't it? Does it has negative effect on the performance.
I don't know how big your project is and I don't have many elements to judge this situation perfectly.
However, working with views means depending on the underlying database system. Obviously it has its pros and cons, but I would prefer to decouple my software components.
What if you change, in the future, switching from MySQL to MongoDB?
Maybe, you could use a cache system, like Redis or Memcached (and Laravel already has a ready-to-use service for it).
As I told you before, I am making this suggestion basically because I think about the software scalability and components decoupling.
Here you can learn about the basic use of the Cache Service: http://laravel.com/docs/5.1/cache
Also, if you have some confidence with design patterns, you can implement a really elegant solution using some stacked repositories alongside the decorator pattern.
You can find some interesting articles about the topic here:
http://culttt.com/2014/02/03/laravel-4-cache-service/
http://culttt.com/2014/04/23/decorator-pattern/
Yes, they're about Laravel 4 but the concept can be easily adopted in a Laravel 5.* project.
Hope it was useful!
EDIT: as I told in the following comments, if you don't want to start with something like Redis or Memcached, you can always use the filesystem-based Cache.
Related
I have the same question about my current project.
Project type: Something like shopping cart SDK.
Models: 30+ (with extensions)
Extensions: 15+
Tables: 47
Relations: every model have 3+ relations
The most performance demanding part processing: 300ms
On start, I have 10 models with relations, that's why I choose Laravel as Framework, and I do not think about growing.
Now, I have 40 models with a lot of extensions and Laravel work fine.
My project is growing fast.
Now It's a big SDK with a lot of tables, relations, and extensions.
I need advice from experienced developers.
Do I need to switch Laravel to Symfony, to reduce future problems with
performance?
I would be glad if you can advise me on this.
P.S.: I understand complexity with migration from Laravel to Symfony,
Performance-wise there is no big difference between frameworks. If you are coding right - they are all just the same.
But the problem is in this part "if you are coding right".
You must always think about design, about responsibilities, about service layers, and to be consistent with your approaches.
And for this Symfony is much better. It's just a more convenient framework to go with SOLID. And it makes you think in a right direction.
TL;DR: There is no any reason to change Laravel to Symfony.
Symfony has no layer for models handling. It's ORM library's responsibilities (usually we can use Doctrine in Symfony -- but it's possible to use another ORM libraries for that -- even Eloquent). And also it's not a big deal to use Doctrine for Laravel.
But obviously changing framework won't decrease the number of models -- so 40 models in Laravel still will be 40 models in Symfony. Because of this, there is no any advantage for decreasing of complexity.
Also there is no explicit dependency between framework and performance (generally, the DB is bottle neck).
Despite of opinion that Symfony automatically (and magically) increases programming skills -- it's wrong. So if someone able follow to SOLID principles, able to reduce cyclomatic complexity of the code, able to provide strong cohesion and loose coopling for the classes -- it doesn't sense what exact framework could be used. Actually Symfony doesn't force to use the best practices.
Therefore Symfony provides a lot of excellent components. But most of them can be used easily (and actually used) in Laravel.
Laravel is good for medium websites. For big app i would always use symfony or zend.
I have an application with a custom framework, it's very old 7 years ago using old techniques and design patterns.
We are facing problems.
We are using DAO Layer to access the Data objects and by the business need things getting so complicated and DAO is no longer being able to serve the business needs, we are thinking to use Symmfony2 and Doctrine2.
But the problem is :
THE APPLICATION IS REALLY BIG.
More than 7 years development and adding features.
About 11.500 Files and File Avg 1500 Line.
I know it's not an easy job, but i'm sure there's a way to migrate or at least use Doctrine for now without hurting the legacy code.
Please Advice.
Thank you.
There is no easy answer to your problems. Dealing with legacy code is always hard.
You should wrap Symfony around your application if possible. Implement a Command or Facade pattern around your app, and make the Symfony controllers call those classes.
Try to separate your DAO access layers by using the repository pattern. Not the Doctrine repositories, but custom ones, specific to your app. When you have repositories separated with interfaces from your app, you can do doctrine implementations of them one by one.
It would be worth thinking about decoupling your application from Symfony so you don't face these kind of problems in the future.
Also, if you can, try to write as many tests as possible, this will make it much easier for you to refactor in the future.
I wrote a blog post with some tips on how to separate from the framework here. The same pattern applies for repositories.
I am starting a new (and first) project with Symfony2, but I didn't choise Database engine yet. And it could be MySQL or NoSQL engines like MongoDB or others, or also it could be changed along the proyect cycle.
So, I would like to start working without limitation of choising Doctrine, Doctrine for Mongo or others. And allowing posibility of changing only model layer without big impact on controllers, and classes.
Recomendations? Comments? Best Practices?
Hope this tutorial will help you to get some knowledge. However try to learn the main concepts before doing any major development.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am a long time PHP user when it comes to web applications and am mostlz comfortable with it. However, I have a one semi-large project whose maintenance / extensibility has reached its end of a life cycle. I was weighing on different PHP frameworks (there were no when the project originated), since it is the way to go for this project, and I came to conclusion the ebst option would be to do it with Zend Framework.
Symfony seemed to complicated (I don't like setting up database model as that
CakePHP seemed murky
Igniter I liked at first, but then it seemed to me it is more like Zend with less features and no Zend behind it
Zend I like the system of that I can use only what I like and not being tied into a specific directory structure, and of course there is Zend behind it. Performance is what potentially bothers me
Now, after this little rationale behind choosing Zend, there are several things I see as a deal breaker when choosing a framework.
I haven't used ORM in the past because I am more than comfortable writing SQL directly, so I still need to be convinced to use ORM
Not too much abstraction going on from the guts
Flexible directory structure
As long as this project is going to be written anew, I just as might write it in Python/Django, since I am quite familiar with Python, but not with Django. So, I would like to know if there is someone that worked with both Zend Framework and Django frameworks and if can outline a few key point differences?
I must also say that this project is made as a standard site/admin dual project. That is, it is basically two sites in one. One is for frontend and users, other is for data administration in the backend. I must and will build backend on my own, some scaffolding methods would be cool, but full automatic scaffolding is as good as nothing in this case.
I am still quite not sure how one approaches building basically two applications within a directory structure of, what is supposed to be, one application. Do you just make two separate applications and rely on URL scheme from there on to separate them? www.example.com and all of the /* being one application and www.example.com/admin/* being a second application.
Sorry for the long question(s), but as you can see - everything is pretty much related to one problem - I need to start a project anew, it has already established database+data which I can remodel, but would like to keep that kind of work at minimum.
Ok, thank you everybody - looks like I'll try and implement this stuff with Zend, gives me most flexibility out of the package (I did tests with both), and we'll see how it goes.
Well Django is more fullstack framework than Zend. It's more similar to symfony than Zend.
Django can reverse engineer your database into ORM classes. and has a cli tool that help you do stuff ( admin and model generators, project skeleton generation etc.)
Zend is more of a component framework. it has its own MVC and ORM implementation but you need to write that stuff alone. Its approach is to use only stuff that you need without imposing some directory structure.
In your case Django will have some advantages because of its great admin generator module, and Django itself is pretty fast (faster than most PHP frameworks).
I'm personally using symfony with Zend framework for some stuff I need (Mail, OpenID, Lucene search), but have played a bit with Django and I like it.
Zend doesn't include a real ORM. It provides some helper classes but you are mostly on your own in modelling your database and writing your own SQL queries. So you would have full freedom there. As Deresh says, Zend is modularized so you can pick and choose the parts you want.
Personally I use Zend together with DB_DataObjects from PEAR as by ORM. It can auto-generate your skeleton code. It is a very simple solution for handling simple queries but I can always write custom SQL where necessary.
Regarding separation of the two admin and frontend I would suggest putting them on different domains, e.g.: admin.yoursite.com (backend) and www.yoursite.com (frontend). You can probably work it with having them both on the same URL but it is not really a use-case that is supported by Django or Zend.
I'm not so experienced with Django, but from what I've read about it, it doesn't seem to be what you're looking for (too much "abstraction from the guts").
Zend framework does not provide you with an ORM. It provides you with some tools that might aid in maintainability of your code (for example its much easier to do $user->save() on a Zend_Db_Table_Row object then to manually type in the equivalent SQL string).
If you're more comfortable doing SQL, that's totally cool and Zend digs that...just beware that there might run into some more maintenance issues down the rode. I would suggest going with a "named query" approach where you store you queries in an external resource and load them "on demand".
Zend has a very flexible directory structure...the recommended one only facilitates in making things a little easier.
You can easily pull of your admin section urls using modules and routing....its a very common use case in Zend.
Bottom line is, Zend is a "presentation framework" mostly. That's what it excels at. It gives you a clean way of organizing the presentation (the screens) that are shown to your users and aids in maintenance.
It doesn't do much for you from a data perspective. This is up to you, and is probably 90% of the work that needs to be done to become "maintainable".
The goal is that your business logic stuff and data access stuff should function within any "framework", and even without a web server! Otherwise you'll just move you unmaintainable mess from whatever you have to Zend.
Also, I wouldn't concern myself with performance...mosy things can fixed with a good caching strategy.
I can't compare between Zend and Django, but I can tell you it's entirely possible to have the Django "admin" application run on a different domain (virtual named server), and you don't need to duplicate any code. You just build your Django app as normal but put the admin app and url in a different virtual server that shares a common database server/cluster.
The Django admin app does have limitations, but it's very powerful for something that comes almost free.
Finally, when I first started Django I had a lot of disdain for ORM's in general but I accept them now as a useful tool in the toolbox.
Most of my experience is on the MSFT stack, but I am now working on a side project, helping someone with a personal site with cheap hosting that is built on the LAMP stack. My options for installing extras are limited, so I'm wondering about how to write my data access code without embedding raw queries in the .php files.
I like to keep things simple, even with .NET. I generally write stored procedures for everything, and I have a helper class that wraps all calls to execute procedures and return data sets. I'm not looking for a full-blown ORM, but it might be the way to go and others who view this question might be looking for that.
Remember that I'm on a $7/month GoDaddy account, so I'm limited to what's already installed in their basic package.
Edit: Thanks rix0rr, Alan, Anders, dragon, I will check all of those out. I edited the question to be more open to ORM solutions, since they are so popular.
ActiveRecord seems to be the state of the art at the moment. I can't recommend any good PHP frameworks for that though. I tried Propel which, while nice, is not easy to set up (especially on a host that you can't install anything on).
Ultimately, I rolled my own ORM/ActiveRecord framework, which is not too much work and very instructive. I'm sure other people can recommend good PHP frameworks.
Take a look at the Zend Framework, specifically Zend_Db. It has a Database Abstraction layer that doesn't require anything other than the MySQLi extension to be installed and isn't a full-blown ORM model.
Maybe Doctrine would do the job? It seems to be inspired by Hibernate.
rix0rrr hit on it a bit, in that many tools are a pain to set up. Of course, I have my own solution to this problem that has been working quite well for the past few years. It's a project called dbFacile
I also wrote a bit of a usage comparison of the tools I found a few years ago. It's incomplete, but might give you a good starting point.
You mentioned that you don't want to embed raw queries but you don't want ORM, so I'm a bit confused about the middle ground you're hoping to find. I also have an ORM project that aims to require minimal setup and great ease of use.
The only requirement for my projects is PHP5.
I would try a framework. Zend Framework has been cited. Symfony seems interesting. It's based on ideas from Ruby on Rails.
You could also take a look at Prado. http://www.pradosoft.com/ It uses Active Record and DAO. Also if you use .Net then some of the formatting and conventions are similar.