Здравствуйте, Tourist, Вы писали:
T>Очень хочеться использовать например что-нибудь типа
T>
T>ResultSet rs = cstat.executeQuery ();
T>MyObjectModel model = new MyObjectModel (rs);
T>
T>заместо
T>
T>ResultSet rs = cstat.executeQuery ();
T>MyObjectModel model = new MyObjectModel (rs.getString(1), rs.getString(2), rs.getString(3));
T>
T>Но почему-то это это не рекомендуется различными паттернами и как мне сказали без объяснений что это плохой стиль
Это не рекомендуется, поскольку в первом случае интерфейс MyObjectModel будет динамическим, зависящим от SQL query, во втором же случае он статичен и не зависит ни от SQL query, ни от ResultSet, ни вообще не отчего (бедный мой русский язык). Туда надо просто передать 3 строки, а ты их можешь достать и из БД, и, например, из конфигурационного файла или ещё проще захардкодить.
T>Кто нибудь сталкивался? Стоит идти против мнения ora.sun или нет?
Конечно стоит. Если силёнок хватит
T>вроде от грамотного применения этого можно только выйграть.
Можно, но я по жизни изхожу из принципа, что можно сделать ещё лучше. В 90% случаев прихожу к тем же паттернам, в остальных — что-то лучшее Зато это самый лучший способ научиться дизайну
забыл написать — уровень доступа к данным лежит ниже (там выбирается какая база или не база и как с ней работать)
а инициализируется раньше
MyObjectModel.Init(...)
MyObjects objs = MyObjectModel.GetObjects( ... )
Здравствуйте, Tourist, Вы писали:
T>Очень хочеться использовать например что-нибудь типа T>ResultSet rs = cstat.executeQuery (); T>MyObjectModel model = new MyObjectModel (rs); T>заместо T>ResultSet rs = cstat.executeQuery (); T>MyObjectModel model = new MyObjectModel (rs.getString(1), rs.getString(2), rs.getString(3));
T>Но почему-то это это не рекомендуется различными паттернами и как мне сказали без объяснений что это плохой стиль T>Кто нибудь сталкивался? Стоит идти против мнения ora.sun или нет? T>вроде от грамотного применения этого можно только выйграть.
Вообще-то, правильно, что не рекомендуют. Так как работаешь с объектом rs, он может быть полиморфным (экземпляром наследника ResultSet), что может повлечь перепроектирования (из-за изменившейя сигнатуры) конструктора MyObjectModel. А в лучшем случае, когда передаётся только объект — rs — нужно будет переписать только ТЕЛО конструктора.
Конечно, всё справедливо только в том случае, если пишется библиотека, и она будет со временем расширяться. В остальном — однохренственно.
Здравствуйте, Banch, Вы писали:
B>забыл написать — уровень доступа к данным лежит ниже (там выбирается какая база или не база и как с ней работать) B>а инициализируется раньше B>MyObjectModel.Init(...) B>MyObjects objs = MyObjectModel.GetObjects( ... )
В принципе все так и реализовано в виде MyOnjectDAO, а вопрос был как в самом методе
MyObjectModel.GetObjects(....) будет иницилизироваться объект MyObjects, писать его конструктор как статичный или можно пробывать ему передать ResultSet чтоб упростить вызов конструктора
у нас реализована идея, что есть некая абстрактная обертка над ResultSet и именно она передается в конструктов MyObjects
получается уход как от конкретики ResultSet так и возможность использовать myRs.GetString( "name" ), Писать new MyObject( myRs ) конечно проще, чем менять параметры конструктора каждый раз как что-то понадобиться
PS использовать rs.GetString( 2 ) конечно нельзя, только по именам
Здравствуйте, Banch, Вы писали:
B>понял
B>у нас реализована идея, что есть некая абстрактная обертка над ResultSet и именно она передается в конструктов MyObjects B>получается уход как от конкретики ResultSet так и возможность использовать myRs.GetString( "name" ), Писать new MyObject( myRs ) конечно проще, чем менять параметры конструктора каждый раз как что-то понадобиться
B>PS использовать rs.GetString( 2 ) конечно нельзя, только по именам
наверно последний вопрос, ну и как? действительно лучше варианта с передачей на прямую параметров или все таки какие-то проблемы возникают с данной архитектурой
как я понимаю в обертке реализована возможность проверки если данный параметр и если его нет соответствующим образом прореагрировать (громко крикнуть на весть код
вобще вариант интересный
T>наверно последний вопрос, ну и как? действительно лучше варианта с передачей на прямую параметров или все таки какие-то проблемы возникают с данной архитектурой T>как я понимаю в обертке реализована возможность проверки если данный параметр и если его нет соответствующим образом прореагрировать (громко крикнуть на весть код T>вобще вариант интересный
никаких проблем вроде нет
независимость от драйверов достигнута полностью
как ты правильно заметил — есть доп возможность проверять все данные на входе и выходе
А я уменя конструктор принимает дискретные аргументы — чтобы можно было тестировать, а конгломераты вроде ResultSet, Stream, File — специализированные фабричные методы (static). Пложу их по мере надобности, благо примитивные получаются. Пока нареканий не было. У клиентов простой код вызова фабричного метода с ResultSet — нет лишнего уровня классов абстракции (тот, который про запас, на случай, если изменится ResultSet ). Очень просто конструктор сделать приватным, тк клиенты с ним не работают, а класс — абстрактным или интерфейсом.