Последние комментарии
Для меня эта страница - это удобный способ смотреть, что нового происходит в комментариях и сразу находить заметку, не заходя в админку. Думаю, она будет полезна и тебе.
Михаил Фленов
Ни в коем случае не призываю изобретать велосипед. Я говорю только о подобного класса вспомогательных прибамбасах. Сторонние компоненты используют здесь без проблем и везде, но только небольшие и в основном отображения.
Все эти сторонние прибамбасы так же в ОБЯЗАТЕЛЬНОМ ПОРЯДКЕ нужно подключать через интерфейсы. Тогда вы сможете легко подменять код третих фирм легко и не принужденно.
ronin
вы что то путаете, при чём тут компоненты отображения данных и запросы, все специфические моменты реализуются в компонентах доступа к данным, а DevExpress только отображает эти данные
для этого существует огромное количество тех же компонентов, как платных так и бесплатных, ничего не надо придумывать
тут я с тобой не соглашусь, то есть ты призываешь бросить весь опыт накопленный другими людьми и начинать изобретать велосипед? лично для меня моё время дорого стоит, и я лучше заплачу 5000 рублей (представь какая это смешная сумма) за библиотеку компонентов доступа к данным и не буду париться по этому, поводу, сэкономлю МНОГО времени, которое я лучше потрачу на вылизывание кода и интерфейса, что бы программа написанная мною была как можно лучше, и я смог заработать денег, а не сидеть и открывать америку заново
может вы тогда ещё предложите VCL переписать заново, если уж пошла такая пьянка?
Михаил Фленов
В Канаде у меня не такой большой опыт работы с разными компаниями, но там, где я работал, ни кто не использовал библиотек типа DevExpress. Везде пишут ручками. И лично я считаю, что эти библиотеки вселенское зло, потому что при их использовании код получается мега привязанным к таким библиотекам и от них отказаться будет на много сложнее.
VVS
функции? я купил например библиотеку компонентов DevExpress за 10000 рублей, а там такой функционал по поиску, фильтрации, сортировке, редактированию и т.д. и т.п. что мне
и за 10 лет такое не написать, смысл тогда заморачиваться с такими вещами? соответственно у меня возникает вопрос о целесообразности
написания класса прослойки для работы с базой данных?
Ведь DevExpress, не сделает автоматическую выборку из БД того что нужно, не предусмотрит какие-то специфические методы? Вы все равно будете делать прослойку между DevExpress и вашей БД.
Если вы не хотите писать запросы ручками, используйте Entity Framework или другую ORM(как я понял DevExpress именно это вам и предоставляет), но вам все равно придеться создавать какую-то прослойку м/у вашей БД и тем что вы используете для доступа к ней.
Серега
Миша, у тебя нагло тырят контент. Вот эту статью http://www.flenov.info/favorite.php?artid=24 стырили сюда: http://yapro.ru/web-master/xhtml/zakoni_verstki_sayta.html
ronin
Захотите мигрировать на другую базу данных, просто создадите еще одну реализацию MyMegaDBOracle и измените одну строку коды и вперед
тут я не понял, например, у меня работа идёт с Mysql, а я решил переходить на Oracle, а там другой синтаксис запросов, другой набор
компонентов доступа к бд с другой реализацией работы с этой базой (свойства, методы, события), что в этом случае значит "одна строка кода"?
мне ведь всё равно прийдётся перелопачивать весь этот класс для того что бы либо добавить этот функционал, либо переписать старый, разве не так?
в чём преимущества данного подхода?
завтра он понимает, что нужно Oracle. А кто-то может не захотеть платить деньги и затребует MySQL. Использование интерфейсов позволит без проблем подменять
классы доступа к данным и прогрессировать с минимальными потерями
это как раз к вопросу выше, как эти потери станут минимальными при таком подходе?
Поэтому такие функции как FindRow, DeleteRow могут быть описаны прямо в базовом классе
я конечно понимаю что может быть я не прав, но при написании проектов (тем более больших) разве сейчас пишут ручками такие элементарные
функции? я купил например библиотеку компонентов DevExpress за 10000 рублей, а там такой функционал по поиску, фильтрации, сортировке, редактированию и т.д. и т.п. что мне
и за 10 лет такое не написать, смысл тогда заморачиваться с такими вещами? соответственно у меня возникает вопрос о целесообразности
написания класса прослойки для работы с базой данных?
Михаил Фленов
Разниц много, но с точки зрения проектирования, все очень даже схоже. Где и что лучше использовать, сказать не могу. Я предпочитаю использовать абстрактные классы для случаев, когда описывается большой класс, и интерфейсы, когда нужно всего пару тройку методов. Просто если у интерфейса всего пару методов, то их можно реализовать где угодно, ведь интерфейсы позволяют множественное наследование и это придает дополнительную гибкость. Если методов много, то я предпочитаю абстрактные классы.
Михаил Фленов
В статье есть тект, похожий на теги <object> и IE проигнорировл это, а FF убил разметку страницы. Исправилено
Денис
Поправьте, пожалуйста, верстку. Текст, после примеров, читать невозможно.
Или это только у меня?
ronin
по сути, если задуматься, то все эти библиотеки и есть классы, только написанные другими людьми, т.е. я отдаю себе отчёт что то о чём пишет Михаил это основа, теория, и так и должно быть, и так и написаны все эти библиотеки, это основа объектно ориентированного программирования, тут в принципе ничего гениального, возникает только вопрос самому писать эти прослойки или использовать чужой труд
для себя резюмирую
основные преимущества использования сторонних библиотек:
1. скорость разработки: ничего придумывать не надо, только подключай и пользуйся
2. качество: я всё таки думаю если человек целыми днями занимается разработкой компонентов доступа к данным, отображения данных и т.д. поболее меня соображает в этом вопросе, поэтому мне кажется что наступать на грабли на которые кто то уже когда то наступал не стоит, на это уйдёт много времени и не факт что ты преуспеешь
3. поддержка новых технологий: думаю здесь всё понятно, субд развиваются, интерфейсы тоже не стоят на месте, за всем не уследишь, и соответственно взваливать на себя непомерный груз не стоит
основные недостатки данного подхода:
1. зависимость от разработчика: тут всё понятно, проект умрёт, остановится развитие и твоего проекта и поддержка новых плюшек в библиотеке, при обновлении например СУБД
p.s. я соглашусь что можно применять подход предложенный автором как раз в небольших проектах, где объём такой работы будет невелик, а в крупных проектах думаю целесообразнее подключать сторонние библиотеки и не выдумывать, хотя если штат программистов велик и ресуры позволяют, то конечно независимость на первом месте
p.p.s ни в коей мере не пытался оспорить принцип описанный в теме, это на 100% правильно но в жизни всё немного сложнее и приходится выбирать, даже в теории БД есть такое понятие как денормализация :)