Здравствуйте!

Описание:
Есть интернет-магазин сделанный на CMS MVC с открытым исходным кодом.

Задача:
к существующему нужно добавить создание товаров и каталог товаров.
Нюанс в том, что новшество делается для совершенно другого типа товара, когда и база, и каталог выглядит совершенно иначе, чем существующий.

Вопросы.
1. лучше создать новую таблицу в базе для нового товара или просто добавить новые поля в существующую таблицу?
2. лучше добавить в существующий контроллер новые методы (для работы с новым каталогом) или создать для нового каталога новый контроллер?

Очень буду благодарен за помощь.

Всем большое спасибо за ответы!
Как мне видится вывод такой: делать, под новый каталог, новую ветку.
Так как:
- старое не сломаешь
- про новое сразу не отгадаешь.

skyANAvladka63, а что за совершенно другой тип товара такой?

Первый тип товара - просто товар - ведро, мячик. т.е нечто материальное
Второй тип товара - услуга.

Так то бы всё ничего, если бы заполнение производилось сотрудниками одной компании. Потерпели бы.
Но речь идет о том, что предлагать свои услуги будут сторонние люди и каждый раз объяснять - что услугу "почесон" - можно заполнять вместе с продажей ведра... заказчик считает - умаемся.. )))

Shocker.ProВвести признак "услуга" в таблицу с товаром. А проблема-то в чем? Не очень понятно.

Во мне )))))
Поэтому разбираюсь.


Форма создания услуги и товара - абсолютно отличаются и каталог выглядит совершенно иначе.

Отсюда и вопрос.

Shocker.Provladka63Форма создания услуги и товара - абсолютно отличаютсяа причем тут база данных? Отличается форма - рисуй отдельное представление.

МСУДа банально вышло новое обновление CMS или сервис пак, который поведет себя непредсказуемотак надо выяснить, на поддержке ли висит эта CMS и планирует ли автор ее обновлять. Или взял какие-то исходники и планирует развивать их самостоятельно


Поэтому и вопрос возник по базе и по контроллеру..
1. Засунуть все в имеющееся или сделать отдельную ветку.


2. взял исходники и развивать сам. Что нужно из обновления выдерну (если будет необходимость)

Shocker.Proразvladka63взял исходники и развивать самтоvladka63Засунуть все в имеющееся

Боюсь запутаться..

Shocker.ProЗубов бояться....

Запутаться можно и в нагромождении кода поверх другого

Т.е получается, что:
в имеющуюся таблицу ставить новые поля, в контроллер новые методы и на основании этих методов создавать представление.
Так?

skyANAvladka63пропущено...


Первый тип товара - просто товар - ведро, мячик. т.е нечто материальное
Второй тип товара - услуга.Услуга - это не тип товара, это отдельная сущность. Для них и правила иные действуют.
Вы поинтересуйтесь у заказчика, чем отличается продажа товаров, от продажи услуг.

Вообщем делайте для них отдельную модель и контроллер.

Я вот тоже к этому варианту склоняюсь.
Описывать в коде отдельную сущность.
Мало ли, что потом стрельнет в голову заказчику..

skyANAvladka63пропущено...


Я вот тоже к этому варианту склоняюсь.
Описывать в коде отдельную сущность.
Мало ли, что потом стрельнет в голову заказчику..А Вы поинтересуйтесь предметной областью заказчика, как он работает.
Чтобы не называть бизнес-процессы словосочетанием "стрельнёт в голову"

Думаете он знает? ))))
Идей фонтан, порой противоречивых..

Shocker.ProskyANAУслуга - это не тип товара, это отдельная сущность.Услуга (особенно фиксированная) очень во многом ведет себя как товар: она может быть представлена в прайс-листе, она может быть включена в заказ, в документы, она может иметь цену и количество так же, как товар (к примеру, в автосервисе тебе "продают" определенное количество нормо-часов, обладающих конкретной стоимостью) и т.п. В то же время услуга может бухгалтерски оформляться по-разному, услуга не приходуется и не расходуется со склада и т.п.

По хорошему, надо ввести некоторую сущность, от которой наследовать и товар и услугу, но, боюсь, в системе, которая изначально рассчитана только на товар, это может быть проблематично. В таких случаях часто услугу считают товаром, делая некоторые корректировки способов проведения и т.п. А создав отдельную сущность "услуга" можно столкнуться с необходимостью продублировать много кода и потом поддерживать модификацию в двух местах.


Т.е в общем-то получается, что, при условии, что ошибки неизбежны, увеличение времени разработки.
Вы об этом?