You have an object that represents something. Let's say cars. So lets say you want to get the VIN, year.. various data on the car. Your car object would have a fetch method (car->fetch()). Your fetch method would contain a CarDao object, (carDao->fetch()). Both would return a CarDto object, that contains the data you expect back, (carDto->getVin(), carDto->getYear()). If there were interfaces in perl, the CarDao and Car would be of the same interface.
Ideally, you can have your sql statements in scalars, near the top of your object, private and do prepares on them so that you have the sql in one place for that object.
In practice, for large projects, this works nicely. If you change your db from mysql to oracle (or soap outside your network), you only have to rewrite your Dao objects. If you change the return type, you change your dto objects and what refers to them for their data.
For small and some medium projects, it's overkill. When working with a team, it feels right too.
In reply to Re: Mixing Mysql and Perl
by exussum0
in thread Mixing Mysql and Perl
by SavannahLion
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |