| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java EE (J2EE) и Spring > net shop design spring mvc + hibernate |
| Автор: gelo86 8.8.2009, 20:09 | ||||
| Вот решил создать ел. магазин. Как известно каждие продыкты имеют свои параметры - телефон например gprs подержкы, а компы в сбою очередь hdd, ram размеры. Вот и думаю как лутше реализовать модели. Есть ы меня две идеи: 1) Все продукты в однои модели (ето просто наброски):
2) Каждый продук имеэт своию модель:
* Первый вариант хорош, потому что через администратара могу создавать варианты опций параметров (PropertyKey), и не надо дла каждого продукта создовать модель + DAO + Test + ... . * Но второй способ дает возможность для каждого продукта цоздать красивый view (html), в первом варианте все параметры в столбик пришлось бы выводить. * Второй способ как я понимаю упрошает select, потому что в where будут перечислятся столбики. В первом варианте пришлось би делать join с другими таблицами. * Во втором варианте PropertyKey пришлось бы делать дла каждого параметра всех модели (model, dao, test, ..). * PropertyKey меныа тревожит тем, что дла полного поиска по всем параметрам приходится с базы данных вытягивать возможные жачения (дла каждото параметра - select * from PropertyKey where name = ?), что снизит performance етих страниц. Как би ви посоветовали реализвать каталог продуктов с параметрами, где для каздото продукта есть список параметров и возможних их значений ? |
| Автор: gelo86 10.8.2009, 19:25 |
| Неуженли у никого нету своего мнения? |
| Автор: garbuz 10.8.2009, 22:57 |
| Тут на мой взгляд надо хорошо подумать. Если вы делаете какое-то одноразовое решение, где количество сущностей ограничено, то наверно будет лучше второй вариант - написал классы, написал DAO для них, вьюхи, контроллеры и все в принципе. Если система должна быть гибкой, масштабируемой, поддерживать большое количество разных сущностей, то скорее подойдет первое решение, не обязательно в том виде, в котором оно у вас есть. Постарайтесь использовать все прелести ООП - возможно определить некий интерфейс, методы которого будут имплементить товары, может быть какой-то родительский класс, от которого можно наследоваться, использовать параметризуемый класс например для того же DAO. Однако на практике чаще всего получаются решения ближе к первому. Имхо как-то так. |