Всем, привет! 
Хочется поднять дисскусию по поводу T*DataSet'a и DBGrid*. 
Текущее положение дел:
На сегодняшний состояние программистов Delphi я бы сказал плачевное, да да именно плачевное.   
Это вызвано двумя проблемами.
 1) Не секрет, что IDE Delphi является интерфейсно ориентированной средой.  Генерит код
таким образом что интерфейс( формочка, кнопочки, их обработчики) увязываются с кодом данных, которые 
нужно обработать. Граммотный подход заключается в использовании системы MVC (model view controller),
которая позволяет разделить классы интерфейса и классы обработки данных. MVC широко используется
в таких средах как JBuilder, Eclipse (для языка Java, да и сама Java использует технологию MVC), также 
фундаментом крутой кросплатформенная библиотеки QT является MVC. 
 2) К Дельфи не применим подход ВСЕ ЕСТЬ ОБЪЕКТ

1 и 2 пункт кодеры на Delphi могут конечно же реализовывать сами, но многие Delphi-программеры
не используют эти подходы, а пользуются тем что навивает нам сама IDE.

К чему все я это рассказываю, для работы с БД мы часто используем готовые T*DataSet'ы (TpFibDataSet, TIBDataSet и т.п.) и готовые гриды, в итоге у нас данные завязываются за интерфейсом. У меня БОЛЬШОЙ вопрос, дорогие форумчане, поделитесь, пожалуйста, своими наработками по использованию средст которые позволяли работать с БД с использованием подхода MVC, мож есть какие-то НЕ TDataSet'ы а другие подходы.

И что же ты молчишь? Продолжай.

А чем тебе эти датасеты не угодили? Работают, и нормально работают, почему не пользоваться?
Причем тут MVC вообще?
Ну не хочешь их на форму кидать, понятно... Да и не правильно это. Для этого надо использовать дата модуль.
Специальный контейнер, для невизуальных компонентов. И все. И пожалуйста, далай себе все в соответствии с MVC.

Akella, так это вопрос был  

Есть, конечно. Изучай API соответствующих СУБД.

Добавлено через 38 секунд

Ну так поднимай, в чём же дело.

эт зависит от форумчан. если им тема интересна, то дисскусия возникнет сама собой

Я мало сведущ в таких высоких сферах, но с датасетами работаю...
Delphist, у меня сложилось впечатление, что тебя не устраивают реализации готовых T*DataSet'ов...
Так какие проблемы? Бери TDataSet за основу и пиши свой TDelphistDataSet и делай в нем все так, как тебе хочется...
Может популярный коммерческий продукт сделаешь...  

так в том то и дело, что не хочеццо ему работать через датасет

Я так понял, что не нравится изолированность данных и отображения.. только ни как не могу понять причемс тут TDataSet и TDBGrid.

ИМХО это надуманная проблема
В сложный проектах всегда используются патерны, когда нужна масштабируемость, расширяемость, а в простых могут быть совершенно другие цели, где можно обойтись без всяких MVC

Если внимательно узучишь компоненты от DevExpress, то там как раз твой MVC и реализован. Думаю и обычный TDBGrid построен на тех же принципах(сто лет его уже не трогал). 

Это сообщение отредактировал(а) cemick - 3.3.2009, 15:12

но в Dev тоже все на датасетах

Датасет выступает только как хранилище данных, в TcxGrid есть на него сслыка, а интерфейс реализуется в TcxGridView, а связывает TcxGridView и TdataSet контроллер TcxCustomDataController. То есть интерфейс ничего не знает о  дата сторадже с его заморочками, у него есть лишь набор строк которые надо отображать

Это сообщение отредактировал(а) cemick - 3.3.2009, 15:13

Не понимаю, чем вам датасет не угодил.



Типа наработка. 
Смотри на это дело так:
Dataset - модель.
Форма - View.
DataModule - контроллер.

Все датасеты - держать только на DataModule. Весь код не имеющий отношения к отображению - только на DataModule. Форма должна уметь только показывать данные, а в обработчикаъ вызывать только соответствующие методы DataModule-я.  
Вот и будет MVC.

Другое дело, что создавать прокси-классы обычно лень, вот и пишем логику прямо в форме. Да и код вроде как понятнее становится. А из минусов "обычного программирования" - для подобного кода становится очень сложно писать юнит-тесты.

Да уж, вижу что никто не пытается применять что-то особенное. Стандартная схема эт, конечно, как говориться как ВСЕ так и я. Хм.. в определенных случаях это избавляет от некоторого гемора, но существующий подход не позволяет легко реализоавть MVC.
Тему я затеял, чтобы узнать чем дышит народ. А то DataSet да DataSet мож что нового появилось, но похоже ничего...

хм.. не всегда стоит повторно изобретать велосипед. Ткм более когда задачей является станок для мотороллеров....
да и Bose, привел ИМХО практически стандартный MVC. То что им не часто пользуются, мое ИМХО это уже сработаная привычка, в малых проектах на которое отводится мало времени - это лишнии затраты, часто более код более наглядный. С большими проектами которые ведутся уже более 10 лет - тоже не будешь весь переписывать, а менять модель посередине проекта глупо, потом вообще концов не найдешь.

Да и вообще, MVC - это хорошо, но не панацея. Всегда надо смотреть на поставленную задачу.

Delphist, почитай, может найдешь для себя че нить интересное

jsa, спасибо за статейку, должна быть интересной. Сейчас немного занят,  но вечерком обязательно прочитаю

Добавлено через 7 минут и 49 секунд
Не останавливаемся на достигнутом.

P.S. Ведь можем же если захочем  

мне наоборот угодил, это вон автору тему не угодил, чем не угодил, спроси у него

Добавлено через 2 минуты и 55 секунд

что? что можем, типо потрындеть без дела?

можем  

Akella, как что? - находить умные статьи, jsa спасибо. Ждем еще..

Добавлено @ 20:08

Без дела не нано, надо по делу.

Я не говорю, что он мне не угодил. Я говорю что подходы нужно менять, а не сидеть из-за дня в день одно и то же. Новые технологии тогда будет прогресс, а иначе регресс

Это сообщение отредактировал(а) Delphist - 4.3.2009, 20:09

Delphist, как уже говорили 

я с этим полностью согласен, так и верно то, что

почему в делфи не используется MVC? я бы сказал потому что скорее всего нет нет такой ярко выраженной необходимости, потому что реализовывать МВЦ - слишком дорогостоящая операция, по сравнению с теми задачами(с большинством) которые решаются на делфи, и прежде всего опять же идет позиционирование на RAD
еще один фактор - ведь что такое МВЦ в корне, как не попытка облегчить себе жизнь - свести программирование как таковое к минимуму + разделение труда, 
Теперь если взглянуть на иерахическую струтуру классов (основу тех же датасетов и гридов) - все очень четко и предельно ясно разделено, причем сразу возникает вопрос - зачем изобретать велосипед, когда можно воспользоваться услугами RAD - т.е. мы отдельно берем Model(БД) + отдельно берем View(Grid) + отдельно берем Controller(элементарный навигатор), связываем их вместе без единой строки кода(практически), често говоря не совсем понятен вопрос, что же ты хочешь получить в качестве

что такое 

не, иначе - стояк  

Зачем тебе MVC? 

Только ради MVC? Или потому что buzzword понравился?   

Можно конечно извратиться и реализовать MVC без датасетов, отказавшись от DB-контролов(ололол!!!!11адинадин), на своих классах(забивая на классы Tfield и TDbXXX контролы). Да в принципе, можно даже взять какой-нибудь готовый фреймворк(есть несколько), который это делает. Но ведь Delphi, в первую очередь, ориентирован на быструю разработку. А изобретая этот велосипед, процесс разработки затянется, к тому же потеряется масса удобств, которые любой Delphi-программист воспринимает как нечто само собой разумеющееся. 

А если без фанатизма - то Delphi спроектирован настолько удачно, что реализует кучу паттернов уже внутри VCL, делая работу программиста с ними настолько прозрачной, что некоторые программисты даже не догадываются об этом.   


В этой статье приводится пример, как реализовать на Delphi паттерн Model View Presentier, не совсем MVC, но общее направление мысли задать может.
A Simple start with MVP in Delphi for Win32, Part 1
А также ресурс http://delphixtreme.com/ - хотя в чистом виде, там инфы по MVC я сейчас не нашёл, но что-то мне подсказывает, что информация размещённая там может быть полезна. =)

Ну и для ленивых - MVC фреймворк на Torry.net
http://www.torry.net/quicksearchd.php?Stri...C&Title=Yes
Сам не смотрел - мне очень лень. =))


ну-ну. Технологии - это одно, а костыли - совсем другое. 

Добавлено через 3 минуты и 14 секунд
+ ещё ссылочки
http://www.carterconsulting.org.uk/MVP.htm
http://sourceforge.net/projects/emvc

http://www.experts-exchange.com/Programmin...Q_23365012.html 
(промотай далеко вниз)

Что-то здесь ничего не нашел, мотал аж до конца

Добавлено через 1 минуту и 30 секунд
Странно все статьи англоязычнае, неужели отечественных нет. Столько русских программистов...  

Нужны пионеры  

Нужны патриоты 

Добавлено через 4 минуты и 49 секунд
Вообще я думаю, не стандартные темы нужно по чаще подымать на этому форуме. Это заставляет делиться нас своими впечатлениями, опытом, общаться. Когда программист постоянно живет только своими мыслями, это к хорошому не приводит.

патриоты чего? русского языка, Delphi, MVC?

русского языка, почему статей на русском по MVC для Delphi не встретишь? Кругом одни буржуи

Это сообщение отредактировал(а) Delphist - 5.3.2009, 13:31

Delphist, у тебя есть вакантное место   , тебе же Kbl4AH намекнул.

Хочешь - будь первым 

или 

В принципе, можно исследовать вопрос и написать. Но за чей счёт банкет?  

И все же мы отходим от темы, ну неужели никто не пытается применять технологию отличающаяся от стандартной

конечно пытаются.

Я вот, например, на днях исправлял ошибки в чужом коде при работе с Firebird-ом из потоков(!). Так вот, программист, который писал тот код отказался от использования стандартных Delphi компонентов IBX, и работал с базой через IBApi.

Добавлено через 1 минуту и 47 секунд
И я так и не понял зачем там использовались прямые вызовы. 

ну не надо х.. с пальцем путать  

Да вижу тема не пошла

Толкай сам ;-)

Расскажи, что именно тебя не устраивает в стандартном подходе, какие альтернативные наработки ты уже нашёл, какие планируешь сделать... ;)

И вообще, что значит не пошла? Мы свою позицию высказали и даже пришли к консенсусу. В Delphi уже есть всё что нужно для использования MVC. Более того, Model и View уже реализованы. Программисту остаётся только сделать контроллер. 

Сталкнулся как-то раз я с кросплатформенной библиотекой QT. По сути на ней базировался когда-то существовавщий Kylix. Так вот при изучении этой библиотеки, выяснилось что она полностью придерживается технологии MVC. Так вот этот MVC совсем иной по сравнению с делфийским MVC. Они совершенно разные. И при программировании с использованием QT ты реально чувствуешь этот MVC. 
Да, конечно, если вести официальный разговор, то можно говорить, да ты че, делфя эта самый, что не на есть MVC вот те модель, вот те View, вот те Controller. Нефига. Как я не стараюсь вручную разделять представление от модели вручную, но делфи волей не волей все равно меня подстигает к тому, что эти две вещи начинают переплетаться в между собой (например в контексте класса интерфейсной формы). Да можете сказать Delphist, да ты клоун и прогер ты хреновый, на что могу с 100% уверенностью сказать на делфи сделать реальный MVC вручную можно, но это такой гемор, это все равно что копать яму лопатой и экскаватором. Если для обычных классов это еще так себе, но если вопрос касается БД то сделать MVC похожий на кутовский вручную задолюаешься.
Вот я и решил поинтересоваться мож что уже предумали для Делфи, какие-нить классы или внешние библиотеки или еще какую-нить бодягу

Это сообщение отредактировал(а) Delphist - 12.3.2009, 19:38

Сорри, но возмущен до глубины души  

Так программируй на QT и сотрясай воздух в соответствущей ветке форума...

ну так копай руками или силой мысли, если можешь...

Ты бы лучше БД лучше (сорри за тавтологию) изучал...

Ты уже поинтересовался 2 страницы назад... Может ты эксгибиционист интернетный? Тебе посты ради постов нужны?

  ага


ну а если серьезно все таки пытал надежды на то, что в Delphi началось что-то появляться подобное. Чувствую что нет, т.к. в противном случае народ бы уже знал и дал бы ответ на мой нелегкий вопрос

Я лично не в курсе. Я только на Delphi работал нормально, а о MVC только читал. 


А вот это уже интереснее. Можно с этого места поподробнее? Про QT слышал много хорошего.  Что такого есть в QT, что нельзя реализовать в Delphi?

И кстати, разве QT нельзя использовать вместе с Delphi? Не в смысле приложений для Kylix, а в смысле, поставить последнюю версию QT и использовать её вместе с кодом Delphi.


   Kbl4AH, приведи лучше пример.

для меня тайна - ты гуру в БД или, наоборот, слабоват? что ты такое делаешь, что тебя не устраивает стандартные возможности?
я не участвоал в дискуссии, т.к. не подкован в терминологии и данной области знаний... но с БД я работаю... поэтому... какая вообще разница - с датамодулем, без датамодуля? смысл один просто код в другом юните, а компоненты на другой закладке... при чем здесь MVC?...
ЗЫ. прошу сильно не ругать, т.к. профан в столь высоких сферах...

Добавлено через 7 минут и 8 секунд

слышал только отголоски, но поделюсь... мой лучший друг программировал на Делфи примерно с 12 по 22 года... а потом стал работать и работать на QT... ну там дали ему время на изучение... но щас он говорит... "Я понял, что Делфи меня тормозило и ограничивало в возможностях программирования"... что он имел ввиду я так и не понял... лично у меня сложилось мнение, что он заворожен просто интерфейсом сделанных программ, что там все очень красиво и т.п. но не более...

КУТ прикрутить к Delphi не получиьтся он поставляется в открытых кодах на C++ и JAVA   


ну насчет слабоват - эт вряд ли.


они вполне VERY GOOD, если писать проекты не большие одноразовые проекты (без дальнейшего развития 
выпустил версию 1.0 и забал про прогу). Если же проект большой и требуется постоянное развитие, то для
его граммотного сопровождения стандратная технология не очень подходит. Объясню почему, дело в том
что труд прогера можно в целом разделить на три момента: проектирование модуля (т.е. до момента кодирования
прогер продумывает логику того модуля ( под модулем имеется ввиду не unit, а подзадачка базового проекта) который
ему предстоит писать); собственно кодирование и наконец отладка, unit-тестирование, иправление текущих багов. 
Кто-то может сказать на хрена козе баян - зачем нам нужно это unit-тестирование, мы и так быстро находим
ошибка и исправляем и патчим - я скажу да, но это справедливо для небольших проектов, для больших проектов
написанных без MVC исправлении бага в одном месте может повлечь за собой ошибки в другом, и в ручную большой
и сложный проект про скандировать весь не получиться, поэтому объязательно нужно unit-тестирования. Но 
опять же написание нормальных unit-тестов возможно лишь в том случае, если проект сделан по принципу MVC, 
в противном случае, можно задолбаться писать эти unit-тесты. Так вот стандартная технология БД далека от истинного
MVC, а это в свою очередь затрудняет нам написание нормального интерфейсно не зависимого проекта ну и как следствие
граммотное написание unit-тестов.    


Это сообщение отредактировал(а) Delphist - 13.3.2009, 13:39

почитал тему - бардак, базар ни очем.



попробовал бы поискать на оф сайте, по конфиренциям. Реально выглядит так.. пришел "дельфист" и задал вопрос "ребята, а неподскажите есть чтото новое для работы с БД, не стандартное, мне влом работать со стандартными компонентами...хочу выпендриится перед сотрудниками... " 

Привел бы свой пример (как ты работаешь с использованием MVC), может другие тоже покажут. ))





Маразм. Работаю девелопером.. проект наш длится уже больше 10 лет (более 5 млн строчек кода). БД MS SQL 2005, архитектура 3-ех звенная (client, application server, database)
UnitTest пишется перед тем как ты начинаешь писать функционал (почитай умные книги), потом начинаешь кодить функционал, постоянно проверяя написанный код UnitTest-ами. 




  

Это сообщение отредактировал(а) X-Vlad - 13.3.2009, 15:07

не согласен

конечно есть случаи (а их очень много в больших проектах) когда нельзя покрыть код юнит тестами, но это иногда говорит о плохой архитектуре проекта.

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

на досуге читаем:
 - "Рефакторинг. Улучшение существующего кода.", Мартин Фауер
 -  Beck, Kent. Test-Driven Development: By Example. Boston, MA: Addison-Wesley, 2003
 - "Совершенный код", С. Макконнелл

Это сообщение отредактировал(а) X-Vlad - 13.3.2009, 15:59

это уже читал, много бреда

там еще две книги )))) не останавливайся на достигнутом ))))   

+500
Писать юнит-тесты для проекта сделанного по принципу: накидали компонентов, настроили связи, подключили всё это к контролам, без выделения функционала в логичные классы - это рельный 3,14здец!  


X-Vlad, скажи пожалуйста ты реально пишешь unit-тесты на delphi в этом db-приложении? Особенно интересует область тестирования application server-a. 
Я веду два проекта с таким же преклонным возрастом(одному более 10 лет, второй помоложе), и при попытке сообразить как покрыть тестами этот код, у меня мозг скукоживается.  Я могу понять как протестировать вспомогательные классы, но как создать mock-объекты для датасетов, я пока не могу сообразить. =( 

Проекты состоят из клиента и бд на firebird-e, сервера приложений просто нет, а большая часть бизнес логики реализована в БД в хранимых процедурах/триггерах.


Дико это звучит пока не попробуешь. А когда попробуешь, то понимаешь, что при таком подходе, классы получаются более цельными и логичными.

ну честно говоря жарптица плохая в ипользовании... разве что в маленьких компаниях и при малых обьемах данных.




У нас нетолько юниттестами покрыт код дельфи, .Net но еще и сторед процедуры. Юзаем как я писал выше MS SQL Server 2005, 2008, базы в стаблицамы в которых несколько миллионов рекордов.
Насчет мокапа данных для тестирования - в ДевЕкспресах есть МемориДатасет, вот в него взаганяешь данные и работаешь с ним, или пишем коллекции и т.д. На проекте более 5000 юниттестов, несколько сотен юниттестов на сторед процы.




бывает такой код который физически невозмождно покрыть юниттестами, мы в таких случаяхъ не напрягаемся 



Это сообщение отредактировал(а) X-Vlad - 15.3.2009, 14:09

Это не имеет отношения к теме. =)


А много людей на проекте?

mock-объекты, это что?

А насколько сильно он отличается от rxlib'овского МемориДатасета?

А вы реально пишите юнит-тесты перед тем как писать объетк?

Это сообщение отредактировал(а) Delphist - 16.3.2009, 14:35

 более 70-ти

Добавлено @ 15:15


если это необходимо. 

Добавлено @ 15:16


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

Добавлено через 5 минут и 40 секунд


не знаю не иследовал. 

Это сообщение отредактировал(а) X-Vlad - 18.3.2009, 15:17

X-Vlad, спасибо за ответы.

Добавлено @ 15:46
Тема все еще актуальна!, так что высказываемся,  не стесняемся 

Добавлено @ 15:48


Почитал стайтеку (http://rsdn.ru/article/patterns/patterns.xml) делаю вывод, что народ все правильно понимает, что я хочу, только вот все это бы к БД, с каким-нить инструментов созданным специально для любителей БД по MVC.

Это сообщение отредактировал(а) Delphist - 18.3.2009, 15:49

народ понимает, что я хочу... какой-нибудь инструмент...  

под иснструментом я имел ввиду  какую-нить библиотеку или фигню типо ECO - только более продивнутую...

Все исчепали мы себя?

Bose, X-Vlad, остальные, поживее-поживее, крутите извилинами, работа-то стоит, работу-то надо работать, а мы из-за вас пролетаем, весь воронеж ждет. я разочарован.

это называется "объектно ориентированное программирование"(с)  


послушайте умных людей 


у этого автора есть еще одна книга: "Patterns of Enterprise Application Architecture", там описаны паттерны проектирования для работы с БД
основная проблема при работе с БД - постоянное преобразование данных из системы типов БД, в систему типов языка программирования, MVC и TDataset этой проблемы не решают. 
Для этого используют различные ORM(object relational mapping) паттерны, которые описаны в этой книге, например Active Record. Существует множество различных ORM библиотек для .NET и для динамических языков, насчет дельфи, я не в курсе.

Добавлено через 1 минуту и 4 секунды
для .NET есть Entity Framework, NHibernate, возможно что-то еще

Добавлено через 14 минут и 35 секунд
Вообще, я не понял, причем тут Dataset-ы и почему они не вписываются в MVC паттерн, согласно MVC, у нас есть data access layer, business logic layer, presentation layer. TDataset, он какбэ часть data access layer, то что он содержит нужно отобразить в набор объектов бизнес логики приложения, которые могут взаимодействовать с presentation layer-ом? По моему, даже на дельфи эти уровни можно разделить и сделать независимыми. 

lol


Мне тоже так кажется, но по-мойму, автор хочет, чтобы ему дали готовый набор компонент "для реализации MVC" 

  расмешил

Скажи, пожалуйста, этот букварь на русском существует или аналогичный книжки на русском

существует  
ЗЫ. Delphist, харош уже заниматься массажем деревянной ноги...

тебя что интересует? MVC в Delphi или руссая документация?
1. тебе кажется уже многие сказали что есть
2. я не искал, если так волнует - поищи, ненайдешь - напиши сам. Заодно и сам разберешься и может другим поможешь. 
А если хорошо напишешь то и книгу выпустишь и денег заработаешь   представляешь MVC в Delphi автор Delphist  звучит      

 )))) На дата модуль бросаем DbConnection, TDataSet, TQuery - вот и появился у нас Data Access Layer
на форму набросали контролов, грид, батоны - вот и presentation layer
ну а Bussiness logic layer можна реализовать по разному в зависимости от Бд которую используешь (например засунуть в Stored Procedures (SQL Server, Interbase, Oracle)) ну или в отдельный юнит в котором реализуешь обработку полученных данных с Data Access Layer.


Вот тебе и MVC 

Ссылочку не дашь.

Добавлено через 3 минуты и 7 секунд

Круто, надо подумать. Delphist уже оставил метку о себе везде даже тут: Delphist+Delphi
А вот книгу еще не написал, надо подумать  

ссылок полно...
очень меня порадовал этот (Букварь для малышей от двух до пяти, 117 страниц, Издательство ООО "ШКОЛА ГЕНИЕВ", Цена: 599 руб.), но как видишь он денюжек стоит  
а тут качай на халяву  

Kbl4AH, жжешь.  

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

так Delphist'a не поймешь, то ему про MVC ссылки нужны, то зачем-то букварь  

Kbl4AH, риальне жжошь!    

Kbl4AH, падсталом, жесть   

Kbl4AH , не хочешь по существу отвечать, то и нечего здесь топик керней всякой засорять.

офф
нуууу судя по оценкам постов...