Jump to content

Recommended Posts

I usually create my own then tweak it slightly for each different project. Sometimes I don't even need to tweak it. Why not write your own?

 

If you ever have to tweak it then it's not very good.

Yeah sometimes I don't need to. I've made it for myself in mind only, so I'm not fussed if I need to tweak it.

I usually create my own then tweak it slightly for each different project. Sometimes I don't even need to tweak it. Why not write your own?

 

If you ever have to tweak it then it's not very good.

Yeah sometimes I don't need to. I've made it for myself in mind only, so I'm not fussed if I need to tweak it.

 

I think you missed the point (or maybe I didn't make it clear enough). There exist some common design principles. One of them is that you should code to an interface, not to an implementation. If you ever need to tweak your classes on a per-project basis then you have coded to an implementation. Another design principle is that your code should be closed for modification while being open to extensibility. You violate that principle as well if you have to tweak your class. This is true whether your application design exists on paper, in your mind, in a file on your computer or any other place.

"One of them is that you should code to an interface, not to an implementation"

 

There isn't anything wrong with creating something specific to an application. If you wanted something so general it would work in all cases without modification you might as well just use the built in mysql functions.

 

Which is what I use btw - don't see any real advantage to wrapping everything in a class. Portability maybe, but the chances we'd ever more from mysql are about as slim as the chances our application would work if we did, even with full-fledged wrapper.

You're missing the point as well. By coding to an interface you are ensuring that the components dependent on that class will not break if you change how everything works. As long as you leave the interface unchanged you can change everything else. Encapsulation is one of the fundamentals of OOP and application design in general. John (448191) has written a bit about it on the main site.

There isn't anything wrong with creating something specific to an application. If you wanted something so general it would work in all cases without modification you might as well just use the built in mysql functions.

 

Which is what I use btw - don't see any real advantage to wrapping everything in a class. Portability maybe, but the chances we'd ever more from mysql are about as slim as the chances our application would work if we did, even with full-fledged wrapper.

 

That's stupid.

 

If you have anything in a simple wrapper class that you can't use the next application, you messed up. And yes, it is true that even with a unified interface, the application's SQL may fail horribly when switching database vendors, or even server versions, but that is why database abstraction and ORM exist.

 

Of course I would never hope to convince anyone who promotes copy/paste coding of anything.

I forgot to mention this, but...

 

[...] but the chances we'd ever more from mysql are about as slim as the chances our application would work if we did [...]

 

That is a major flaw in your application design. You may use a few more hours in the initial programming phase and those hours will be well earned compared to the amount of hours you would have to waste because your lack of being able to take change into consideration. You may not want to change away from MySQL, but your client/boss might want to and then you're in deep shit if you haven't coded it properly from the start. When designing your app you should always take change into consideration (even if it's unlikely).

Maybe you guys are just in a different situation than me.

 

My company has one big project - our clients are the people that use it. I coded the entire thing by myself, with some minor exceptions (date pickers, lightboxes, mysql backup class, SMTP email class, FCK editor)

 

My boss doesn't care what database engine we use. We're using mysql because I wrote it with mysql. I always use mysql, because I've never ran into a situation where it didn't do what I wanted it too. Yes, if I went in tomorrow, and he said to use mssql, I'd be screwed. If he said make a multilingual version I'd be screwed too, but that doesn't mean I'm going to put all my strings in a big include file.

 

All the flexibility you write in to the codebase is a trade off - you have to weight the chance something will happen against the time it will take to account for it, sometimes the flexible approach is the best one, but I don't see how you can just say it is 'right'.

 

Oh well, I'm going to go copy a contact form, paste it into a control panel, and change variable names till I have a message board :)

lol, sorry that last bit was funny.

 

Anyway, if you don't want to lose performance with an abstraction layer, I started off using MSSQL in my company, developed my own db class.  Since then I've just copied it for MySQL and changed it all to do the MySQL features.  You can do that for any db you like, call the functions the same and you just have a bunch of DB classes to choose from depending on what project you do, simple.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.