Архитекторы, подскажите, плз.

Все, что вы хотели знать о программизме, но боялись спросить.
vg
Маньяк
Сообщения: 2803
Зарегистрирован: 29 май 2003, 22:29
Откуда: Магадан - Миссиссага

Сообщение vg »

современные репорт-компонент могут подключать xml, mdb и заполнять данные в шаблоне.
Спасибо за мнение, Лепсик.
По существу. Если имеешь ввиду компоненты, что идут с BCB++, то не интересно. Конечно, там движением руки всё рисуется. Но я здесь публику напрягаю с VB.NET. Нашёл библиотеки xml(разумеется+xsl) to rtf. Платное.
http://www.schema.de/sitehtml/site-e/xmlnach0.htm
или
http://www.rtf2fo.com/
У MS - пока ничего не видел. Может плохо смотрел. Доверяю только им. Хочется или от M$ готовое, или сорц классов.
Про другие современные компоненты не знаю. Подскажи. :(
Аватара пользователя
Lepsik
Житель
Сообщения: 522
Зарегистрирован: 17 фев 2003, 18:34
Откуда: Berlin
Контактная информация:

Сообщение Lepsik »

вот тебе на .NET.
делает то же самое

http://www.datadynamics.com/Products/Pr ... duct=ARNET


Я вот всегда поражаюсь менеджерам - почему они думают что смогут програмерам правильно выбрать инструменты и компоненты. :)

Всегда ! (не помню исключений) когда манагеры требовали чтобы я делал по ихнему уходила всегда бездна времени на такие решения.
А зачастую решения такие не работали и приходилось переделывать
vg
Маньяк
Сообщения: 2803
Зарегистрирован: 29 май 2003, 22:29
Откуда: Магадан - Миссиссага

Сообщение vg »

вот тебе на .NET.
делает то же самое

http://www.datadynamics.com/Products/Pr ... duct=ARNET
Спасибо за ссылочку.
Я вот всегда поражаюсь менеджерам - почему они думают что смогут програмерам правильно выбрать инструменты и компоненты.

Всегда ! (не помню исключений) когда манагеры требовали чтобы я делал по ихнему уходила всегда бездна времени на такие решения.
А зачастую решения такие не работали и приходилось переделывать
Лепсик, простые зададачи должны решаться простыми средствами. Те задачи, о которых я пропостил в данной нитке - простые. Из разумно решать на VB. Ты попробуй сделать проект на VB. Для простых задач - гораздо круче, чем на С. Преимущества VB:
1) скорость разработки гораздо выше

2) качество кода, думаю выше по количеству сделанных ошибок местными "профи", программирующего на С или Делфи.

3) ты будешь смеяться, но крутые "С++" перцы нам не нужны для выполнения этой части проекта. В отпуск их, или пусть ищут работу в Канаде. :lol: Платим немного, программирующим на VB. Выгодно.

4) по контракту программер оставляет сорц. Мои хлопцы в отделе (не программеры) в состоянии внести изменения в VB код, если это будет необходимо при небольших инфлюенциях инфраструктуры инф.системы. Это не задумка. Это реальность. Эта работа делается всегда в отделе. В коде VB они разбираются неплохо. В "С" - нет. Чтобы разработать и поддерживать одно из указанных выше приложений для одной из форм - не нужно обращаться в фирму-разработчику:
http://www.giga_C_or_Borland_programmers.com.
Нас не устраивает ситуация, например, когда при мизерном изменении структуры базы мы должны перезаключать новый контракт с девелопером, и он за большие деньги вносит маленькие изменения в код.

Конечно, могу ошибаться. Дай критику конструктивную. А не так, ты мол vg ... манагер... Конструктивнее аргументируй. :D

ПС. Про VB. Лепсик, я конечно не настолько крут, как ты. Говорю без иронии, скромно. На С я программирую с 1987. Это к тому, чтоб было понятно, что я люблю этот язык. Но ты не представляешь, как я тащусь от VB.NET в сравнении с ахинеей C при решении простых задач. Попробуй. Почуствуешь разницу.
Аватара пользователя
Lepsik
Житель
Сообщения: 522
Зарегистрирован: 17 фев 2003, 18:34
Откуда: Berlin
Контактная информация:

Сообщение Lepsik »

--1) скорость разработки гораздо выше

в чем ? a = B + 3 пишется однаково быстро.

отсутствие ООП в VB делает кода на 90% больше.
Я вообще искренне жалею программистов не знавших что такое STL и програмирование с патернами.

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

собственно я могу сравнивать - я делаю на С++ примерное тоже самое что они на VB.

Функциональность у низ ниже хотя толковые ребята.На более примивный query builder для фиксированной структуры базы у них ушло месяц у меня для меняющейся структуры неделю.


3) ты будешь смеяться, но крутые "С++" перцы нам не нужны для выполнения этой части проекта. В отпуск их, или пусть ищут работу в Канаде. Платим немного, программирующим на VB. Выгодно.

неправильный вывод. Язык не не должен влиять на стоимость оплаты - только профессиональный уровень.
Ну будешь ты платить в двое меньше - так и качество разработки в 5 раз ниже.

4) по контракту программер оставляет сорц. Мои хлопцы в отделе (не программеры) в состоянии внести изменения в VB код, если это будет необходимо при небольших инфлюенциях инфраструктуры инф.системы. Это не задумка. Это реальность.

Это другой вопрос.

--ПС. Про VB. Лепсик, я конечно не настолько крут, как ты. Говорю без иронии, скромно. На С я программирую с 1987. Это к тому, чтоб было понятно, что я люблю этот язык. Но ты не представляешь, как я тащусь от VB.NET в сравнении с ахинеей C при решении простых

ты просто давно не программировал на С++. Сейчас уже другое время
Аватара пользователя
dima
Житель
Сообщения: 690
Зарегистрирован: 19 фев 2003, 19:26
Откуда: Хабаровск->Toronto

Сообщение dima »

Lepsik писал(а):--ПС. Про VB. Лепсик, я конечно не настолько крут, как ты. Говорю без иронии, скромно. На С я программирую с 1987. Это к тому, чтоб было понятно, что я люблю этот язык. Но ты не представляешь, как я тащусь от VB.NET в сравнении с ахинеей C при решении простых

ты просто давно не программировал на С++. Сейчас уже другое время
если от .NET ташишся, то бери C# (оказалось что не все что можно сделать на C# с такой-же элегантностью делается на VB). Я C# пробовал - просто класс. Сделал что-то вроде WinSql (для ODBC только), но этот .NET framework рушится с постоянной завидностью. .. и не у меня одного, в news groups народ жалуется на те-же проблемы при использовании ODBC.
vg
Маньяк
Сообщения: 2803
Зарегистрирован: 29 май 2003, 22:29
Откуда: Магадан - Миссиссага

Сообщение vg »

Lepsik,

В целом по твоему постингу... К сожалению, ты не увидел главного. Впрочем, как и dima. Пост был главным образом про простые задачи, а не сравнение языков вцелом. Было сказано, простые задачи решаем простыми средствами (например, VB), сложные задачи - более сложным инструментом. А ты STL .... Хотя ... Может просто тебе показалось, что задачи, что у меня решают девочки на VB - это сложные для тебя задачи. Ну, тогда да.... Извини. Но тогда и STL не поможет ...
Теперь несколько замечаний по твоему постингу в мелочах.
--1) скорость разработки гораздо выше

в чем ? a = B + 3 пишется однаково быстро.
Не очень понятна математическая формула.
отсутствие ООП в VB делает кода на 90% больше.
Надо понять для чего нужен VB. Если недостаточно тех COM, что есть - напиши дополнитель свои на VB, или на C (кстати не обязательно ++). Можно и купить эти библиотеки.
Попробуй разок использовать COM в VB. А в целом на VB не принято писать сервера, могутные приложения с GUI. Другими словами, меру надо знать. К чему ты про ООП - я не пойму :(
Я вообще искренне жалею программистов не знавших что такое STL и програмирование с патернами.
Не обижайся. Но мне кажется, что ты не знаешь, что такое паттерны проектирования. Шаблоны STL, ATL и т.д. с одной стороны и паттерны с другой стороны - это разное. Современные IDE для Windows платформ не имеют встроенной поддержки паттернов. Да и не могут иметь. Паттерны используют и определяют, как правило, спецификации интерфейсов IDL (interface defenition language). Имплементация паттернов - вообще десятое дело. И ещё, строго говоря, паттерны вообще не имеют отношения к ООП модели программирования. Ты спутал pattern и temlate.

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

собственно я могу сравнивать - я делаю на С++ примерное тоже самое что они на VB.

Функциональность у низ ниже хотя толковые ребята.На более примивный query builder для фиксированной структуры базы у них ушло месяц у меня для меняющейся структуры неделю.
В C++Builder ты можешь использовать TQuery или TADOQuery (обётка борланда для ADO) и соответствующие компоненты DataBase, если есть необходимость управления транзакциями. В VB используй рекордсеты ADO или ADO.NET.
Ничего писать и соревноваться не нужно.

3) ты будешь смеяться, но крутые "С++" перцы нам не нужны для выполнения этой части проекта. В отпуск их, или пусть ищут работу в Канаде. Платим немного, программирующим на VB. Выгодно.

неправильный вывод. Язык не не должен влиять на стоимость оплаты - только профессиональный уровень.
Ну будешь ты платить в двое меньше - так и качество разработки в 5 раз ниже.
Это только твоё мнение. Деньги наши и программеры Магаданские, а не Берлинские. Нам виднее кому и как платить в России.

ты просто давно не программировал на С++. Сейчас уже другое время
Я же постил, что не такой профессиональный, как ты. Буду стараться.

dima,
если от .NET ташишся, то бери C# (оказалось что не все что можно сделать на C# с такой-же элегантностью делается на VB).
Ты прав в части простоты и эффективности разработки на C# приложений средней сложности. Но мне удобнее, если те протые приложения, о которых шла речь были сделаны на VB. Моей команде удобне будет разбираться потом с сорцами VB, а не С#.

Что ж до меня, то мне удобнее в С. Хотя шарп безусловно проще. Более того, такое ощущение, что поддержка Window::Forms в IDE VS.2003 более устойчива для #, чем для С++. Это просто мои наблюдения. Основаны наблюденя на том, что сложная форма Window::Forms эксплорер-подобного приложения в C++.NET "разваливается" в дизайнере. Таких эффектов нет в С#.

Я C# пробовал - просто класс. Сделал что-то вроде WinSql (для ODBC только), но этот .NET framework рушится с постоянной завидностью. .. и не у меня одного, в news groups народ жалуется на те-же проблемы при использовании ODBC.
ODBC достаточно старая технология. Используй ADO или ADO.NET. Кстати, ADO поддерживает и сокеты к ODBC (см. ConnectionString ). Ты можешь использовать DSN ODBS в конекшен стринг ADO.

И ещё.... Не хочу возбуждать словесную диарею некоторых здешних деятелей (не буду показывать пальцем), но мне, кажется, разумно написать свои обёртки, которые конфигурировались бы из текстовых файлов на клиенте. Там ты можешь указать текстовой строкой, какие имеенно объекты доступа к данным должны быть использованы на клиенте, и там же прописать конекшен стринг. Другими словами, если устойчиво работает ODBC - в конфиге просто указывешь тип объектов="ODBC", конекшн_стринг="Твой DSN ODBC". Если увидел , что в существующей инфраструктуре на клиенте ODBC работает не устойчиво, то в конфиге указываешь тип объектов="ADO", конекшн_стринг="Строка твоего OLEDB провайдера". Всё. Никаких изменений в код клиента вносить не надо. Отруливается только изменениями в текстовом конфиге на клиенте. Я давно уже это использую. Работает. Очень удобно. Если интересно, то можешь написать в приват своё мыло. Пришлю вордовский файл (дока для программеров к одному из моих проектов с сорцами). Рагмер файла около мегабайта.
Аватара пользователя
Lepsik
Житель
Сообщения: 522
Зарегистрирован: 17 фев 2003, 18:34
Откуда: Berlin
Контактная информация:

Сообщение Lepsik »

--В целом по твоему постингу... К сожалению, ты не увидел главного. Впрочем, как и dima. Пост был главным образом про простые задачи, а не сравнение языков вцелом.

да я не против. Мне сложнее со стороны смотреть как у тебя там все живет.


--Не очень понятна математическая формула.

Я хотел сказать на С++ можно писать так же просто как и на VB.


--Но мне кажется, что ты не знаешь, что такое паттерны проектирования.
--И ещё, строго говоря, паттерны вообще не имеют отношения к ООП модели программирования.

Вообще-то у меня там перечисление стояло.

--Паттерны используют и определяют, как правило, спецификации интерфейсов IDL (interface defenition language).


В моем представлении ООП и паттерны всегда жили вместе, как и не только в моем. Порознь - с трудом.
http://www.mathcs.sjsu.edu/faculty/pear ... apter1.htm

--мне удобнее, если те протые приложения, о которых шла речь были сделаны на VB. Моей команде удобне будет разбираться потом с сорцами VB, а не С#.

Судя по тенденции проект VB в MS постепенно закрывается, с переносом упора на C#.
Тут я с Димой согласен лучше бы вашим на программистам на C# мигрировать


--Это просто мои наблюдения. Основаны наблюденя на том, что сложная форма Window::Forms эксплорер-подобного приложения в C++.NET "разваливается" в дизайнере.

наверное что-то неправильно написал. А пока все еще много жалоб на усточивость Framework
vg
Маньяк
Сообщения: 2803
Зарегистрирован: 29 май 2003, 22:29
Откуда: Магадан - Миссиссага

Сообщение vg »

Судя по тенденции проект VB в MS постепенно закрывается, с переносом упора на C#.
Тут я с Димой согласен лучше бы вашим на программистам на C# мигрировать
Трудно не согласиться. На перспективу, думаю, ты прав. Но народ на столько прикипел к VB, что .... не знаю. Другая проблема, которая может встать, и о которой я пока ничего не знаю - как быть в приложениями для ArcGis. У нас версия 8.3. В своё время вбухали бабок на лицензии немало. Там кастомизируется оболочки ArcView/ArcEdit при помощи VBA или C++. C# - и не пахнет. Как будет дальше - не знаю. Кроме того, много приложений с VBA MS Access (тот ещё гимор). Хотя, может и рано об этом задумываться.
--Это просто мои наблюдения. Основаны наблюденя на том, что сложная форма Window::Forms эксплорер-подобного приложения в C++.NET "разваливается" в дизайнере.

наверное что-то неправильно написал. А пока все еще много жалоб на усточивость Framework
Конечно, не правильно. Но просто правила VS - совершенно уродские. В билдере никогда такого не было. Там ты можешь свободно любую форму (*.cpp, *.h, *.dfm ) перетащить из одного проекта в другой. В VSC++.NET для Windows.Forms - так просто не получится. Вернее у меня не получается. Короче, никогда MS не догнать Борланд в части нормальности работы визуальных средств разработки ГУИ. Отстой, имхо. Как был отстой для разработчиков MFC или WinAPI, так и остался отстоем (хоть и чуть меньшим) в дизайнере для форм .НЕТ.
Ответить