심포니 대 cakephp

심포니 대 cakephp

---

개념적으로 Symfony와 cakephp의 차이점은 무엇입니까?

---

이 스레드의 균형을 맞추기 위해 심포니를 좋아하는 이유입니다.

• PHP5 사용
• Yahoo! 와 같은 정말 큰 사이트를 실행합니다. 답변, 맛있고 데일리 모션 .
• 좋은 문서. 웹 사이트의 jobeet 튜토리얼은 굉장합니다. 모든 기능을 곧바로 안내하며 작업을 마치면 무엇이든 만들 수있는 것처럼 느껴집니다.
• 고도로 모듈화되어 있습니다 . 많은 심포니 구성 요소가 자체적으로 작동합니다.
• 당신이 선택할 수 있습니다 중 하나를 추진 또는 당신의 ORM으로 교리. 교리는 정말 훌륭하고 사용하기 쉽습니다.
• YAML 또는 PHP로 모델을 정의 할 수 있습니다. 어떤 사람들은 구성 파일을 좋아하지 않으며 YAML을 피하려면 실제로 사용을 제한 할 수 있습니다.
• 업데이트 된 심포니 CLI (1.2 기준)는 굉장합니다. 나는 abales에 동의합니다.이 버전 이전에는 약간 불안정했지만 이제는 매우 잘 문서화되어 있으며 예측 가능한 형식을 따릅니다.
• 물론 PHP가 Ruby (!)만큼 예쁘거나 유연하지 않다는 점을 제외하면 레일 위의 루비와 많은 유사점이 있습니다. 그러나 케이크 개발자와 이야기하면 아마도 그 반대라고 말할 것입니다. :)
• ( 심포니 에도 존재하는) CRUD에서 한 단계 올라간 심포니 관리자 생성기 는 엄청난 시간을 절약 해줍니다. 데이터 모델을 사용하여 목록보기 (인덱스), 페이지 생성 및 편집 이 포함 된 사용자 지정 가능한 관리 인터페이스 를 생성 합니다. 소스를 생성하고 들어가서 수정하는 기본적인 문제가 아닙니다. 실제로 각 필드의 모양, 포함 할 필드, 각 개체에서 수행 할 수있는 추가 작업 등을 정의 할 수 있습니다.

개념적으로 차이점은 다음과 같습니다.

• CakePHP는 학습 곡선이 더 작습니다. MVC 프레임 워크를 사용 해본 적이 없다면 Cake는 짧은 시간 안에 쉽게 선택하고 실행할 수 있습니다.
• Symfony는 느리다고 말하는 것이 아니라 "더 크게"느낀다.하지만 필요할 때 많은 고급 작업을 수행 할 수있는 많은 코드가 있습니다.

제가 드릴 수있는 가장 좋은 조언은 두 가지 모두에서 자신 만의 간단한 데이터 모델을 빠르게 설정하고 몇 가지 기본 인터페이스를 실험하고 자신의 코딩 스타일에 가장 적합한 것을 확인하는 것입니다. 두 프레임 워크 모두 매우 활동적이고 열정적 인 사용자 커뮤니티를 가지고 있으며 어떤 식 으로든 결정을 후회하지 않을 것입니다.

---

• CakePHP 철학은 Ruby on Rails와 유사합니다.
• CakePHP는 중형 프로젝트에 더 좋습니다.
• CakePHP는 배우는 것이 더 빠릅니다.
• CakePHP는 심포니보다 가볍습니다.
• CakePHP의 데이터베이스 상호 작용은 CRUD를 사용합니다.
• CakePHP는 테스트 시스템 PHPUnit을 사용합니다.
• CakePHP Bake 및 스캐 폴딩에서 흥미 롭습니다.

---

• Symfony의 철학은 버전마다 다릅니다.
• Symfony는 학습 속도가 느립니다.
• Symfony는 대규모 프로젝트에 가장 적합합니다.
• Symfony의 Database Interaction은 Doctrine을 사용합니다.
• Symfony는 테스트 시스템 PHPUnit을 사용합니다.
• Symfony의 번들 및 템플릿에서 흥미 롭습니다.

---

모델이 생성되는 방식에 큰 차이가 있습니다. CakePHP 모델은 PHP로 작성되고 Symphony 모델은 YAML로 작성되고 Propel에 의해 구동됩니다. CakePHP의 접근 방식은 ROR의 ActiveRecord와 더 유사합니다 (정확히 AR 구현은 아니지만). 일반적으로 CakePHP는 레일과 비슷합니다.

내 생각에 CakePHP의 문서와 도구는 더 넓은 대상 독자를 가지고 있으며 구문과 도우미가 더 쉽지만 아직까지 PHP5를 독점 대상으로 채택하지 않았습니다 (자동 로딩은 실제로 존재하지 않습니다). 일반적으로 저는 CakePHP의 접근 방식이 확립 된 표준을 따르기 때문에 선호하며 그 조직에 박수를 보냅니다. PHP5의 장점 때문에 Kohana 를 추천 합니다.

거기에 또 다른 포스트 자사의 초점이 서로 다른 비트하지만이 질문에 대한 스택 오버 플로우가.

편집 : 나는 내가 '아니오'라고 말한 이유를 찾기 위해 Symfony를 수정했고 다음을 생각해 냈습니다. 귀하의 의견과 마일리지는 다를 수 있습니다.

CakePHP는 또한 죽은 단순한 스캐 폴딩과 이해하기 쉬운 CLI 도구를 제공합니다. Symphony의 CLI 구문은 약간 이상하고 Symfony의 'CRUD'는 동일하지 않습니다. 이를 Symfony의 (awkard) 작업 구문과 결합하고 Symfony의 잘못 디자인 된 (이해하기 어려운) 웹 사이트와 타사 유료 문서 (Amazon의 책) 선호도를 사용하면 단점 열에 더 많은 틱이 있습니다.

---

CakePHP와 위의 제한 사항에 대한 일부 주장은 사실이 아닙니다. 쿼리가 가능합니다. 당신은 그것을 만드는 방법을 알아야합니다. CakePHP의 "자동 마법"은 매우 훌륭하므로 빠르게 실행할 수 있습니다. 개발에 대한 가장 빠른 프레임 워크는 BY FAR입니다 (따라서 RoR을 매우 밀접하게 모델링 한 이유는 분명히 큰 성공과 화제였습니다). 데이터를 다르게 반환하고 몇 가지 짧은 메서드 호출과 배열 매개 변수를 지정하여 더 복잡한 쿼리를 수행하는 고급 동작이 있습니다.

하나. 내가 말할 수있는 한, 다른 프레임 워크에는 "자동"메소드와 클래스가 많이 없습니다. Cake는 가장 일반적인 작업을 수행하고이를 수행하는 쉬운 방법을 제공합니다. 정말 영리하다면 모델 수준에서 대부분의 코딩을 수행하고 app_model 및 app_controller 파일을 사용하고 매우 효율적인 애플리케이션을 갖게됩니다.

콘솔은 훌륭하고 항상 확장됩니다. 커뮤니티는 정말 놀랍고 더 빠르게 진행할 수 있도록 많은 기여가 있습니다. 필요한 대부분을 사용할 수 있기 때문에 문자 그대로 설계 한 다음 "조각"을 제자리로 이동하여 앱을 매우 빠르게 빌드 할 수 있습니다. 다른 프레임 워크로는 얻을 수 없습니다. 일반적으로 코딩에 더 많은 시간을 투자해야합니다.

마지막으로. 문서가 뒤처졌지만 지금은 훨씬 더 나았고 Cake도 문서가 부족하고 버전 1.1 기간 동안 가혹한 리뷰를 받았지만 여전히 훌륭했습니다. 1.2와 이제 Cake2와 Cake3이 다가 오면 ... 많은 의견이 바뀌는 것을 보게 될 것입니다.

1.1부터 CakePHP를 사용했습니다. 나는 그것을 굳게 믿는다. 거대한 기업 사이트에 사용했습니다. 그것은 하루에 수백만 건의 히트를 받고 있습니다 ... 우리는 솔루션을위한 WordPress 및 Drupal과 같은 영역에서 벗어났습니다. CMS 유형 사이트의 해당 수준에 도달하면 CakePHP가 포함되어 매우 기쁩니다. 마찬가지로 Symfony와 CodeIgniter는 확장을 도와줍니다. 두 프레임 워크에 대해 나쁘게 말할 수는 없습니다. 나는 당신이 더 적은 시간을 코딩하고 CakePHP로 더 큰 커뮤니티 (그리고 매우 친숙한 IRC 채널)를 찾을 것이라고 말할 수 있습니다.

---

나는 CakePHP에 대한 위의 의견에 대한 내 응답 중 일부를 살펴보고 문서화하고 있으며 일부는 (어떤 경우에는 올바르게) 인식 된 결함입니다.

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.

ReferenceURL : https://stackoverflow.com/questions/1242060/symfony-vs-cakephp