Bambr

Скажите, а на кой черт вам перл, если Вы на нем пишете как на баше?

$Date = `date +%d-%m-%Y-%H.%M`;
use POSIX 'strftime';
$Date = strftime('%d-%m-%Y-%H.%M', localtime);

$log = «Backup.'$DBname'.'$Date'.txt»;
Можно воспользоваться советом выше про chomp, это правильнее. А можно выкосить все переводы строк уже из собранной переменной $log, в данном случае это чуть короче:
$log =~ s/[\r\n]//g;

system «echo '$log' > temp.log»;
open my $fd, ">", «temp.log» or die «Can't open temp.log: $!»;
print $fd $log;
close $fd;

Да, это явно длиннее, но и намного эффективнее. Форкать процесс чтобы узнать дату или записать строчку в файл, это как-то совсем грустно…

Был у нас когда-то магазин, перл+ООП, так что все написанное ниже — субъективный опыт и описание конкретной реализации, а не строгая догма.
Во-первых, все очень хорошо и с пользой разбивается на объекты. Часть объектов мысленно «можно потрогать» — к ним можно отнести объекты юзера, товара, объект корзины с подъобъектами-позициями (товар + колво), объект заказа с позициями (товар+колво+зафиксированные цены) и много всякой другой мути. Часть объектов «потрогать» уже сложнее, но их введение тоже дает профит благодаря полиморфизму и наследованию — в этой категории, например, у нас оказались объекты, отвечающие за реализацию различных способов доставки и оплаты. Как обычно, наиболее интересным и не слишком простым оказалось все это увязать в единую систему. Многие объекты в обе стороны зависят друг от друга, но тем не менее избежать циклических связей удалось.
Что вам могут дать объекты? Самый наглядный пример — это, конечно, товар. Предположим, у нас есть две таблицы — с книгами и дисками — и классы ActiveRecord, прикрученные к ним. Начинаем определять, что же нам нужно от товара. По большому счету, это цена (с валютой, если есть необходимость) и название. Остальное менее интересно и может пригодиться в частных случаях. Например, для расчета стоимости почтовой доставки пригодится информация о весе, а для всяких маркетинговых штучек — поле «цена со скидкой» (для красоты чисел удобнее не задавать это поле в процентах). Определяем методы, которые будут эту информацию возвращать. Допустим, захотелось сделать комплекты из нескольких товаров. Заводим новый класс, для которого можно будет определить свое название и цену со скидкой, цена без скидки суммируется по входящим в комплект продуктам. Ну и так далее, на странице товара его можно отображать как угодно и полей может быть сколько угодно, «корзинка» же видит свой набор полей, и только его. По большому счету, если у нас уже есть система, умеющая книги, прикрутить к ней комплекты — цена написания одного небольшого класса с парой обязательных полей.
Доставка также обладает названием, стоимостью, произвольным образом зависит от содержимого корзины, адреса доставки, может быть валидной или невалидной в данных условиях (как правило, курьерская доставка в Петропавловск-Камчатский невозможна). Аналогично и с оплатой, но она зависит также и от доставки (нельзя оплатить курьера наложенным платежом).
Корзина включает в себя информацию о товарах, юзере, доставке и оплате. Заказ — до боли похож на корзину, но вся информация, которая может измениться, в нем сохраняется отдельно. Измениться могут например цены, адреса.
Если приступить к реализации, начните с простого — с товаров и корзинки. Подумайте, что такое корзина, что в нее входит кроме товаров, сколько корзин может быть у юзера, возможна ли «анонимная» корзина. Первые два вопроса позволят вам решить, какие поля и методы должны быть у объекта, вторые два — как получить конкретный объект корзины, когда захочется показать ее на странице. Реализуйте то, что получилось, пока без доставок и оплат, но чтобы на экране выглядело «как у всех». Добавляйте постепенно остальное, ищите места, где можно сделать несколько разных реализаций чего-либо при одинаковом интерфейсе — возможно, это можно будет выделить в отдельный объект. Но без необходимости тоже не крошите, будет сложно собрать в одно целое :)

Как-то так. Успехов!

Mojo достаточно прост и имхо вполне подойдет для дипломной работы. Про Catalyst тут уже писали. Mason весьма мощная штука, но для обучения имхо неудобен, ибо поощряет смешивание логики и представления, а до его самых вкусных плюшек вы вряд ли доберетесь сразу. Для обучения, как написал metamorph, хорошо помогает писать велосипеды «по мотивам» лучшего, что вы встретили у других.
ЗЫ если будете выбирать обертку над БД, умоляю, НЕ берите DBIx::SearchBuilder.