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

Я вот, например, на днях исправлял ошибки в чужом коде при работе с 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

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

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