On Thu, Dec 9, 2010 at 7:41 PM, Daevid Vincent <dae...@daevid.com> 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

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.


Reply via email to