On Thu, Dec 9, 2010 at 7:41 PM, Daevid Vincent <daevid@xxxxxxxxxx> wrote: > I disagree. If you use a framework, then you're stuck with it. Bugs and all > (and trust me there are bugs and limitations you WILL run into). I have fixed bugs locally in third party libraries; I have submitted them for patching; I have received fixes from other people for them; and I have had them accepted. This must be factored in to your choice of tool. Don't go with the project that hasn't had any commits in over a year. Also, projects lead by a single person with no other committers bring risk. > If it's your code, you can fix it. > If it's your code, you are the only eyes looking at it and the only one that can fix it. It's a trade-off. Doubtful. It's hard enough to find skilled PHP developers as it is. > If that's the case, you're already behind the eight ball. Whether you use someone else's code or your own, they won't be able to learn it. At least with an outside tool there's a slim chance they've worked with it before. That's just it. DO NOT make a "framework". Make some helper routines for > common tasks like sql_query(), sql_insert(), sql_update(), > sql_select_box(), etc. and stick to the "basics". > This discussion started about ORM, and I think we've moved on to third-party libraries. By using "framework" as you have, you're narrowing the conversation considerably to a handful of libraries at most (Zend, Cake, any others for PHP?). By framework I mean a collection of related helper routines, classes, methods, etc. that make performing a specific access of coding easier. [I wrote] > > Nor will you get > > help with bugs in your framework or be able to discuss > > better ways to use it on forums. > > That's what your employees, team-mates, customers, testers, etc. are for... > I prefer my network of help to include thousands of coders rather than a handful. If you're making "JoeBlowsRinkyDink.com" then go for the framework if you > want to play with it for the massochistic experience and to learn your > lesson the hard way. But don't use it for paying customers and certainly > don't use it in an enterprise level -- it will be the death nail to your > project ultimately. > I've successfully used frameworks for small customers, large customers, in the enterprise and at startups. I've also written my own libraries to perform more narrow tasks in the same environments. Use the right tool for the job; don't be dogmatic in your decisions or you'll end up wasting time or other resources. To bring this back around to ORMs specifically, if you are going to build a lot of database-driven applications and you want to use object-oriented techniques rather than passing around a bunch of arrays, take some time to investigate the options. If you find a tool you like, your time investment to learn it will pay off in spades with each new project. You only need to learn it once; it will save you time again and again after that. David
