История такая, долгое время сидел на 1С, потом какое-то время использовал дельфин. Уровень подготовки средний.
Есть идея написать систему с трехзвенной архитектурой:

Что бы был SQL Server (написанный понятное дело кем)
Что бы был сервер приложений (среднее звено) — написанный мной
Что бы были клиенты (тонкие) — написанны мной приимущественно на VC но потенциально и с помощью других сред разработки (VB,DELPHI,BUILDER, Web-клиент и т.д.).

Основная задача данной системы — комплексное управление предприятием, приимущественно учетные задачи, но и не только они

Обязательно условие — основную разработку вести на VC++ (на данный момент у меня установлена Visual Studio .NET)
Т.е. что бы Среднее звено и основной набор клиентов были написаны на VC. Ну и при желании на других языках.

Меня интересует с чего начать изучение VC — что бы в максимально короткие сроки приступить к разработке указанной выше задачи. Возможно, есть какие либо примеры, или статьи по этому поводу. С радостью приму — указание на статью или раздел MSDN где подробно про это написано (может мне повезет и там есть пошаговая инструкция
Опыть программирования для Windows имеется ( в основном делфейский) некоторые прототипы я разработал на Delphi и даже опробовал. Использовал технологию Midas. Знаком и умею использовать технологию COM/DCOM (правда испльзоавал только в Delphi, и немножко в 1С)

Да еще одно очень важное замечание: Пожалйста не отговаривайте меня использовать VC, и не предлагайте основную разработку вести на каких либо других языках. Мне это не интересно: что лучше — что хуже я уже осознал и сделал свой выбор, в детских перебранках типа "чья песочница лучше?! "участвовать нежелаю (такого начитался уже достаточно). Т.е. мораль такова подскажите в какую сторону, рыть, где читать, смотреть пробовать. В таком духе.

Заранее спасибо за помощь.

P.S. Ах да, чуть не забыл, и советов что "мол сам такое не потянешь", "...пустая трата вреени и денег...", "... зачем изобретать велосипед..." пожалуйста тоже постарайтесь избежать. Колечество работы, усилий и затрат я трезво оцениваю. Знаю и в данном вопросе их попрошу не рассматривать

P.P.S. Посылать в Яндекс, Апорт и другие поисковые системы, тоже ненадо, все что мог с их помощью достать я достал. "Может плохо искал раз сюда обращаюсь" — скажете вы? Отвечу, я хочу получить грамотную консультацию, возможно правильный совет, а то что пишут в статьях в некотором роде отличается от того что мне нужно.

Здравствуйте, mvg_first, Вы писали:

MF>Да еще одно очень важное замечание: Пожалйста не отговаривайте меня использовать VC, и не предлагайте основную разработку вести на каких либо других языках. Мне это не интересно: что лучше — что хуже я уже осознал и сделал свой выбор, в детских перебранках типа "чья песочница лучше?! "участвовать нежелаю (такого начитался уже достаточно). Т.е. мораль такова подскажите в какую сторону, рыть, где читать, смотреть пробовать. В таком духе.

Мда, тяжелый случай, лёгкие пути не для нас, понимаю

По серверу берёшь книжку по ATL и вперёд. К тому же понадобиться ADO. Для клиентской части MFC. Думаю за годик всё это реально изучить, а там уже можно будет начинать и что-то делать.

Здравствуйте, mvg_first, Вы писали:

MF>История такая, долгое время сидел на 1С, потом какое-то время использовал дельфин. Уровень подготовки средний.
MF>Есть идея написать систему с трехзвенной архитектурой:

Самому и без опыта? Не советую. Разве что поэкспериментировать.

MF>Обязательно условие — основную разработку вести на VC++ (на данный момент у меня установлена Visual Studio .NET)

Не советовал бы. Лучше что нибудь более под сервера приложений заточенное — джаву или любой из языков дотнета.

MF>Меня интересует с чего начать изучение VC

Так ты его еще и не знаешь? Так почему тогда такое желание на С++ писать?

MF> — что бы в максимально короткие сроки приступить к разработке указанной выше задачи.

На С++ без его знания, сервер приложений без опыта написания онных и в короткие сроки? Ты меня пугаешь.

MF>Возможно, есть какие либо примеры, или статьи по этому поводу. С радостью приму — указание на статью или раздел MSDN где подробно про это написано

Очень ты обще обрисовал. По этой теме полно статей и здесь и на MSDN и еще много где.

MF>Опыть программирования для Windows имеется

Не поможет

MF>Да еще одно очень важное замечание: Пожалйста не отговаривайте меня использовать VC, и не предлагайте основную разработку вести на каких либо других языках. Мне это не интересно: что лучше — что хуже я уже осознал и сделал свой выбор, в детских перебранках типа "чья песочница лучше?! "участвовать нежелаю [i](такого начитался уже достаточно). Т.е. мораль такова подскажите в какую сторону, рыть, где читать, смотреть пробовать. В таком духе.

И все же я бы посоветовал очень серьезно задуматься над средством разработки. Приведи хотя бы основные причины почему тебе столь сильно хочется именно на С++?

MF>P.S. Ах да, чуть не забыл, и советов что "мол сам такое не потянешь", "...пустая трата вреени и денег...", "... зачем изобретать велосипед..." пожалуйста тоже постарайтесь избежать. Колечество работы, усилий и затрат я трезво оцениваю.

Если оцениваешь трезво то скажи — во сколько человекочасов ты оцениваешь проект?

MF>P.P.S. Посылать в Яндекс, Апорт и другие поисковые системы, тоже ненадо, все что мог с их помощью достать я достал. "Может плохо искал раз сюда обращаюсь" — скажете вы? Отвечу, я хочу получить грамотную консультацию, возможно правильный совет, а то что пишут в статьях в некотором роде отличается от того что мне нужно.

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

Здравствуйте, IT, Вы писали:

IT>Думаю за годик всё это реально изучить, а там уже можно будет начинать и что-то делать.

Добрый ты человек, IT, да еще к тому же и оптимист

Здравствуйте, AndrewVK, Вы писали:

MF>>Меня интересует с чего начать изучение VC
AVK>Так ты его еще и не знаешь? Так почему тогда такое желание на С++ писать?

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

Здравствуйте, mvg_first, Вы писали:

MF>Обязательно условие — основную разработку вести на VC++ (на данный момент у меня установлена Visual Studio .NET)
MF>Т.е. что бы Среднее звено и основной набор клиентов были написаны на VC. Ну и при желании на других языках.

Ну, если ты используешь .NЕT, то лучше обратить внимание на C#, тем более, что есть опыт в дельфях. Легче будет, серьезно. Это про middle tier. А вот клиенты лучше на VC — возможно быстрее будет на слабых клиентских машинах.

ЗЫ: В идеале — в качестве клиента использовать браузер

Здравствуйте, Igor Soukhov, Вы писали:

IS>так изучать что-то новое не на кошках а на оплачиваемом проекте — самое
IS>что ни на есть наиприятнейшее занятие... И деньги плотять и резюме от
IS>подтвержденного коммерческого опыта толстеет.

Вот только сервера приложений в качестве кошек не очень. И непонятно требование приступить очень быстро.

AVK>Вот только сервера приложений в качестве кошек не очень. И непонятно требование приступить очень быстро.

Да он похоже под сервером приложений понимает не собственно сервер приложений как некую инфраструктуру для исполнения server-side applications и ряд сервисов (транзакции, секьюрити etc), а server-side components, бизнес-объекты в простонародье.

Здравствуйте, mvg_first, Вы писали:

MF>История такая, долгое время сидел на 1С, потом какое-то время использовал дельфин. Уровень подготовки средний.

Была бы голова на плечах. А с этим, похоже — полный порядок.

MF>Есть идея написать систему с трехзвенной архитектурой:

MF>Что бы был SQL Server (написанный понятное дело кем)

Бяда... Значит — ADO придётся всё-таки изучить. На всякий случай, напоминаю — на MS-SQL свет клином не сошёлся. Есть ещё ряд серверов: DB/2, Oracle, Cache, Interbase... Список можно продолжить.

MF>Что бы был сервер приложений (среднее звено) — написанный мной

Определись — универсальный сервер приложений или какие-нибудь невнятные бизнес-объекты? Если второе — то путь твой несчастен и пользователи тоже... (ИМХО, разумеется ) Мои рекомендации относятся к универсальному серверу.

MF>Что бы были клиенты (тонкие) — написанны мной приимущественно на VC но потенциально и с помощью других сред разработки (VB,DELPHI,BUILDER, Web-клиент и т.д.).

Тыыкс... значит, коммуникационная среда "клиент--middle-tier" всё-таки DCOM... Ладно, отобьёмся. Только скажи мне, на кой уповать на "разные среды разработки"? Это всё можно решить много позже, путём предоставления соотв. интерфейсов.

MF>Основная задача данной системы — комплексное управление предприятием, приимущественно учетные задачи, но и не только они

Это очень расплывчато. Поясню почему. АСУ в своей ипостаси управления предприятием может тащить всё, вполть до realtime-обработки. Так что... Но с другой стороны, посылка сия стала основой моего предположения о том, что тебе нужен универсальный сервер.

MF>Обязательно условие — основную разработку вести на VC++ (на данный момент у меня установлена Visual Studio .NET)
MF>Т.е. что бы Среднее звено и основной набор клиентов были написаны на VC. Ну и при желании на других языках (выделено мной — ГВ.).

Вот этого (выделено) лучше не надо до устаканивания инфраструктуры. Почему? Потому что затащишь прежде времени что-то вроде COM/DCOM на middle-tier — через короткое время ляжешь под объёмами работ по реализации. Да и гибкость будет — не пришей кобыле хвост... Плавали, знаем...

MF>Меня интересует с чего начать изучение VC — что бы в максимально короткие сроки приступить к разработке указанной выше задачи. Возможно, есть какие либо примеры, или статьи по этому поводу. С радостью приму — указание на статью или раздел MSDN где подробно про это написано (может мне повезет и там есть пошаговая инструкция

В принципе, примеров и статей по этому поводу — просто море. Но на русском языке — в основном туфта про "наисовременнейшие технологии".

Попробую кое-что посоветовать.

Инструкция теоретическая:

1. Закладывайся на то, что прикладники в дальнейшем будут работать только с твоим API. Никаких ADO/OLE/COM/JNI и проч. на их уровне не должно быть.

2. Тебе понадобится проработать и понять для себя ряд принципиальных вопросов:
2.1. Жизненный цикл объектов (в т.ч. — версионность);
2.2. Ограничение доступа (эту тему нужно проработать заранее. Нетничего хуже, чем вшивать security в уже спроектированную систему — вся предыдущая работа летит к чёртовой бабушке... или получается кастрированная защита);
2.3. Объектно-реляционное отображение (что отображать? как отображать? как управлять транзакциями?);
2.4. Обработка ошибок;
2.5. Управление памятью (стандартные new/delete очень плохой советчик);
2.6. Отображение информации (интерфейс пользователя, отчёты);
2.7. Распределённая обработка (коммуникации);
2.8. Связь с какими-то CASE-системами (необязательно, но может пригодиться).

Есть и другие вопросы...

3. Рекомендации по п.2 таковы:
Прорабатывай всё до предела своей фантазии — если защита, то защита вплоть до конкретной точки (конкретного поля конкретного объекта), если обработка ошибок, то вплоть до возможности исправления ошибок нехватки памяти. Никаких пошаговых уточнений. Поверь на слово, гораздо проще отказаться от чего-то впоследствии, чем выдумывать что-то с учётом свежеполученных ограничений.

Инструкция "лабораторная":

Очень большая нагрузка ляжет на generic-программирование, поэтому займись этой темой по возможности немедленно. "Поиграй" с шаблонами на C++. Собственно говоря, именно с этим связана следующая инструкция.

Инструкция праткическая:

1. Выкинуть нахрен компилятор MSVC++ и никогда о нём не вспоминать, пока он не начнёт поддерживать ANSI-стандарт.
2. Заменить его, например, на Intel C++ 6.0 (встраивается в VS.NET, относительно поддержки managed extensions не знаю...)

Инструкция психологическая:

Тебя будут грузить со всех сторон. Наибольшую опасность представляют непосредственные сотрудники и руководители, которые нахватались информации (не практических знаний!) о наисовременнейших технологиях, ускоряющих всё и вся. Здесь тебе понадобится всё самообладание, цинизм и искусство логических построений. Учти, в IT-индустрии принято пинать тех, кто не следует моде.

На что посмотреть:

Посмотри K2, ACE. Ссылки на кое-какие материалы есть на RSDN здесь. Если не работают, свисти — кое-что у меня, кажется сохранилось. Но там тоже бредней хватает

MF>Опыть программирования для Windows имеется ( в основном делфейский) некоторые прототипы я разработал на Delphi и даже опробовал. Использовал технологию Midas. Знаком и умею использовать технологию COM/DCOM (правда испльзоавал только в Delphi, и немножко в 1С)

Главное — чтобы понимал внутреннюю структуру C++-программы. Ну, ещё понимал как AddRef/Release/QueryInterface в ATL работают. Это — фундамент.

MF>Да еще одно очень важное замечание: Пожалйста не отговаривайте меня использовать VC, и не предлагайте основную разработку вести на каких либо других языках. Мне это не интересно: что лучше — что хуже я уже осознал и сделал свой выбор, в детских перебранках типа "чья песочница лучше?! "участвовать нежелаю (такого начитался уже достаточно). Т.е. мораль такова подскажите в какую сторону, рыть, где читать, смотреть пробовать. В таком духе.

Я не собираюсь тебя отговаривать. Если нужно — пиши приватом. Чем смогу — помогу. ИМХО, универсальное App-ядро — едва ли не единственный путь не ожидать в трепете и страхе очередного виража IT-моды. Как следствие — сохранение инвестиций в проект. Долговременное. C++, судя по всему, и дотнет и Java переживёт, пока они мутировать будут.

MF>Заранее спасибо за помощь.

MF>P.S. Ах да, чуть не забыл, и советов что "мол сам такое не потянешь", "...пустая трата вреени и денег...", "... зачем изобретать велосипед..." пожалуйста тоже постарайтесь избежать. Колечество работы, усилий и затрат я трезво оцениваю. Знаю и в данном вопросе их попрошу не рассматривать

Звучит несколько самонадеянно, уж извини. Это не означает, что ты "не потянешь", "не сможешь" и т.п. Во-вторых — не переживай, этих велосипедов нормальных-то и нет ни разу, чтобы ни жужжали апологеты.

На самом деле, реально написать такой сервер на 6-8 месяцев (это если одному), и за 4-6 если вдвоём. Но больше трёх лучше в такую разработку не брать (по крайней мере — поначалу) — ими управлять зашьёшься. В твоём случае, я бы добавил ещё месяца по три.

MF>P.P.S. Посылать в Яндекс, Апорт и другие поисковые системы, тоже ненадо, все что мог с их помощью достать я достал. "Может плохо искал раз сюда обращаюсь" — скажете вы? Отвечу, я хочу получить грамотную консультацию, возможно правильный совет, а то что пишут в статьях в некотором роде отличается от того что мне нужно.

Про поиск в рунете я уже говорил. Здесь в основном переводные рекламные статьи и восторженные бредни. Кое-что можно посмотреть на softcraft.ru, но там, в общем, теории много.

За конкретными советами лучше давай в приват. Не откажу.

Дерзай, в общем. Немедленно .

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Тебя будут грузить со всех сторон. Наибольшую опасность представляют непосредственные сотрудники и руководители, которые нахватались информации (не практических знаний!) о наисовременнейших технологиях, ускоряющих всё и вся. Здесь тебе понадобится всё самообладание, цинизм и искусство логических построений.

Это ты из личного опыта?

ГВ>Учти, в IT-индустрии принято пинать тех, кто не следует моде.

Да, потрепала тебя жизнь...

ЗЫ. Есть у меня один кореш на работе, опыт в программинге более 10 лет. Был архитектором, но упёрто не хотел следовать моде. Сейчас просто старший девелопер, сидит хвосты подгребает и сапортит всякое старьё на плюсах. Попытки втолковать, что моде надо следовать никакого воздействия не оказывают, видимо наслушался таких как ты, испортил себе карьеру, скорее всего потеряет в зарплате и вообще его будущее как специалиста мне теперь представляется весьма туманным.

ЗЫ2. Он, кстати, считает, что если надо, то он всё за две недели возмёт, все эти шарпы и дотнеты, и очень легко избавится от старых стереотипов. Но что-то вот пока никак.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Тебя будут грузить со всех сторон. Наибольшую опасность представляют непосредственные сотрудники и руководители, которые нахватались информации (не практических знаний!) о наисовременнейших технологиях, ускоряющих всё и вся. Здесь тебе понадобится всё самообладание, цинизм и искусство логических построений.

IT>Это ты из личного опыта?

И из него — в том числе.

ГВ>>Учти, в IT-индустрии принято пинать тех, кто не следует моде.

IT> Да, потрепала тебя жизнь...

Отнюдь. А вот тебя, похоже, да... Уж извини.

IT>ЗЫ. Есть у меня один кореш на работе, опыт в программинге более 10 лет. Был архитектором, но упёрто не хотел следовать моде. Сейчас просто старший девелопер, сидит хвосты подгребает и сапортит всякое старьё на плюсах. Попытки втолковать, что моде надо следовать (выделено мной. — ГВ.) никакого воздействия не оказывают, видимо наслушался таких как ты, испортил себе карьеру, скорее всего потеряет в зарплате и вообще его будущее как специалиста мне теперь представляется весьма туманным.

Увы и ах. Если уж в обществе принято следовать моде, то иной раз поневоле приходится. Кстати, а кто-нибудь реально сопоставлял то, что делал этот деволпер не следуя моде с тем, что делает команда, следующая моде? Или просто кривили носы — "фи, устаревшие технологии!"?

IT>ЗЫ2. Он, кстати, считает, что если надо, то он всё за две недели возмёт, все эти шарпы и дотнеты, и очень легко избавится от старых стереотипов. Но что-то вот пока никак.

Хех Ну, с оценкой сроков я в некоторых местах погорячился Почти сознательно. А про "две недели" — сам когда-то таким был. Вырос. Вообще, по наблюдениям — "две недели" это что-то вроде магического жезла. Если у программиста спросить, что ему нужно, чтобы перевернуть мир, он ответит — "две недели".

Здравствуйте, mvg_first, Вы писали:

MF>История такая, долгое время сидел на 1С, потом какое-то время использовал дельфин. Уровень подготовки средний.
MF>Есть идея написать систему с трехзвенной архитектурой:

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

готов к потоку КОНСТРУКТИВНОЙ критики

Здравствуйте, Геннадий Васильев, Вы писали:

IT>> Да, потрепала тебя жизнь...

ГВ>Отнюдь. А вот тебя, похоже, да... Уж извини.

Т.е. получается, что ты и жизни то не видел

Меня она не то чтобы сильно потрепала, но многому научила. В частности, выводы сделанные мной таковы: сомой большой ошибкой, которую может себе позволить девелопер — это игнорирование новых тенденций в индустрии. Мне как-то довелось попыть безработным в штатах в течении 3-х месяцев, так вот моё пренебрежение явой в своё время могло мне очень дорого обойтись. Наличие пусть небольшого, но реального опыта увеличило бы мои шансы найти работу как C++ программиста ровно в два раза, т.к. многие позиции требовали вместе Java/C++.

ГВ>Увы и ах. Если уж в обществе принято следовать моде, то иной раз поневоле приходится. Кстати, а кто-нибудь реально сопоставлял то, что делал этот деволпер не следуя моде с тем, что делает команда, следующая моде? Или просто кривили носы — "фи, устаревшие технологии!"?

Он делал на DCOM/C++ то, что можно было сделать на шарпе в два раза быстрее. В результате, за этот срок требования к задаче изменились на столько, что в том виде, в котором она была сделана, она уже была не нужна. Пол года работы в мусорку. Если бы он её сделал быстрее, то она ушла бы в производство с урезанным функционалом, а он бы мог потратить оставшееся время на изменение и доработку фич.

Справедливости ради надо отметить, что в конторах подобным моей, акценты в разработки ПО несколько смещены. В частности, гибкость процесса разработки, гораздо важнее гибкости производимого софта. Нужно быстро сделать и быстро отдать в производство. Проекты длиннее 3-х месяцев разбиваются на фазы и делается сначала первая версия с урезанными функциями, затем делается вторая и т.п. Я всю жизнь работал в других условиях, мой корешь тоже. Мы привыкли к длинным проектам. Проект длинной в пол-года считался для меня коротким. Теперь всё по другому и старые методы разработки здесь просто не работают. Новые технологии, тот же .NET, как нельзя лучше вписываются в наши сегодняшние задачи. Но мой корешь это тоже понять не хочет... или не может.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>1. Закладывайся на то, что прикладники в дальнейшем будут работать только с твоим API. Никаких ADO/OLE/COM/JNI и проч. на их уровне не должно быть.

Практически. Полностью вряд ли удасться от них избавится. Но как направление следует использовать.

ГВ>2.1. Жизненный цикл объектов (в т.ч. — версионность);

По моему вопрос №1 при проектировании, но про него почему то обычно забывают.

ГВ>2.3. Объектно-реляционное отображение (что отображать? как отображать? как управлять транзакциями?);

И нужно ли вобще. А может плоские таблицы или xml.

ГВ>2.4. Обработка ошибок;
ГВ>2.5. Управление памятью (стандартные new/delete очень плохой советчик);

Это сильно зависит от платформы. К примеру в джаве и дотнете эти вопросы уже решены.

ГВ>2.7. Распределённая обработка (коммуникации);

Здесь обязательно надо подумать о балансировке. Потом вряд ли удастся ее добавить.

ГВ>На самом деле, реально написать такой сервер на 6-8 месяцев (это если одному), и за 4-6 если вдвоём.

Кхм ...

Здравствуйте, IT, Вы писали:

IT>Т.е. получается, что ты и жизни то не видел

Видел, впрочем ладно. Давай, закроем эту тему в таких фразеологизмах.

IT>Меня она не то чтобы сильно потрепала, но многому научила. В частности, выводы сделанные мной таковы: сомой большой ошибкой, которую может себе позволить девелопер — это игнорирование новых тенденций в индустрии. Мне как-то довелось попыть безработным в штатах в течении 3-х месяцев, так вот моё пренебрежение явой в своё время могло мне очень дорого обойтись. Наличие пусть небольшого, но реального опыта увеличило бы мои шансы найти работу как C++ программиста ровно в два раза, т.к. многие позиции требовали вместе Java/C++.

Понимаешь... твои выводы актуальны для тех, кто вынужден принимать условия "как есть". mvg_first всё-ж-таки начальник отдела (загляни в профайл), ему под силу, надеюсь, сформировать часть таких условий исходя из своих соображений. ИМХО, такой путь для него — более адекватный.

IT>Он делал на DCOM/C++ то, что можно было сделать на шарпе в два раза быстрее. В результате, за этот срок требования к задаче изменились на столько, что в том виде, в котором она была сделана, она уже была не нужна. Пол года работы в мусорку. Если бы он её сделал быстрее, то она ушла бы в производство с урезанным функционалом, а он бы мог потратить оставшееся время на изменение и доработку фич.

Мда... клинический случай. Вот тут я с тобой соглашусь. Конкретные условия существования списывать со счетов нельзя. Вредно для психики. Порой — необратимо.

IT>Справедливости ради надо отметить, что в конторах подобным моей, акценты в разработки ПО несколько смещены. В частности, гибкость процесса разработки, гораздо важнее гибкости производимого софта. Нужно быстро сделать и быстро отдать в производство. Проекты длиннее 3-х месяцев разбиваются на фазы и делается сначала первая версия с урезанными функциями, затем делается вторая и т.п. Я всю жизнь работал в других условиях, мой корешь тоже. Мы привыкли к длинным проектам. Проект длинной в пол-года считался для меня коротким.

У меня как раз всё наоборот было... Это к длинным проектам привыкать приходилось. С планами, стадиями и проч. Хе-хе...

IT>Теперь всё по другому и старые методы разработки здесь просто не работают. Новые технологии, тот же .NET, как нельзя лучше вписываются в наши сегодняшние задачи. Но мой корешь это тоже понять не хочет... или не может.

Естественно не все телодвижения IT (я не тебя имею ввиду ) делаются ради моды самой по себе. У Java и у .NET есть свои вполне адекватные области применения. Держаться зубами и ногами за нечто одно-единственное, и на мой взгляд тоже — глупо. Просто не всегда уместно обобщать свой частный (а он всегда частный) опыт. Вот ты говоришь относительно своего опыта и своей конторы — и всё становится на свои места... А то бы я тут разнаезжался.

еще раз прошу прощения у почтеннейшей публики

Вы писали:

MF>Основная задача данной системы — комплексное управление предприятием, приимущественно учетные задачи, но и не только они

господа. уважаемые. данной теме (автоматизации предприятий) посвещены специализированные, порой очень не тривиальные системы (наши, западные — не суть). изобретение еще одного велосипеда (читай АСУ предприятия) занятие наверняка увлекательное, познавательное, но, имхо, ДЕСТРУКТИВНОЕ, для этого самого предприятия. спросите у манагера, буха, директора — на чем он хочет клиентскую часть: на asm'е, с++, прочих # — он на вас посмотрит с непониманием в лучшем случае. ему подлецу, понимаете, хочется чтобы она подлюга (программа) работала. представляете, каков мерзавец? плевать он хотел на средство разработки. и, что самое обидное, они правы .

спор, на тему как дешевле: самим писать, или что готовое покупать и дорисовывать под себя, так же встречался много раз. в вашей ситуации, думаю будет не дороже. но уж точно предприятие выиграет по срокам внедрения. ну не придется ему ждать, пока Команда Разработчиков, таки проштудирует всю мыслимую литературу по средствам разработки, напишет пачку ХелоуВорлдов в серверных и клиентских вариантах , и сможет наконец снизойти до низких материй — ейной автоматизации.
вы также останетесь в выигрыше по крайней мере по количеству выживших нервных клеток

MF>P.S. Ах да, чуть не забыл, и советов что "мол сам такое не потянешь", "...пустая трата вреени и денег...", "... зачем изобретать велосипед..." пожалуйста тоже постарайтесь избежать. Колечество работы, усилий и затрат я трезво оцениваю. Знаю и в данном вопросе их попрошу не рассматривать

вы, извиняюсь, директор этого самого предприятия? если нет, то это просто ЭГОИЗМ. уж если хочется разбираться с высокими технологиями, зачем лезть в низкие материи (учетные задачи)? полно задач в науке, технике и т. д. до куда 1С и ей подобные не добрались. там и писать-то интереснее.

по-прежнему готов к потоку КОНСТРУКТИВНОЙ критики

Здравствуйте, AndrewVK, Вы писали:

ГВ>>1. Закладывайся на то, что прикладники в дальнейшем будут работать только с твоим API. Никаких ADO/OLE/COM/JNI и проч. на их уровне не должно быть.

AVK>Практически. Полностью вряд ли удасться от них избавится. Но как направление следует использовать.

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

ГВ>>2.4. Обработка ошибок;
ГВ>>2.5. Управление памятью (стандартные new/delete очень плохой советчик);

AVK>Это сильно зависит от платформы. К примеру в джаве и дотнете эти вопросы уже решены.

Хм... ИМХО, GC — это не решение, а закрывание глаз на проблему, точно также, как и Stack Trace по поводу ошибок.

ГВ>>2.7. Распределённая обработка (коммуникации);

AVK>Здесь обязательно надо подумать о балансировке. Потом вряд ли удастся ее добавить.

Эт-точно. Кстати, весьма смежно с вопросами ограничения доступа.

ГВ>>На самом деле, реально написать такой сервер на 6-8 месяцев (это если одному), и за 4-6 если вдвоём.

AVK>Кхм ...

Кхм два раза. Признаю — погорячился кое в чём.

Здравствуйте, BME, Вы писали:

BME>спор, на тему как дешевле: самим писать, или что готовое покупать и дорисовывать под себя, так же встречался много раз. в вашей ситуации, думаю будет не дороже(выделено мной — ГВ.). но уж точно предприятие выиграет по срокам внедрения. ну не придется ему ждать, пока Команда Разработчиков, таки проштудирует всю мыслимую литературу по средствам разработки, напишет пачку ХелоуВорлдов в серверных и клиентских вариантах , и сможет наконец снизойти до низких материй — ейной автоматизации.

А основания для подобных утверждений каковы? Особенно — по части штудирования мыслимой литературы и ХеллоуВорлдов? И кстати, про добавленную стоимость слышал? Как ты думаешь, в каком случае она будет больше (для предприятия-внедренца)? В случае продажи готовой системы или разработки своей? Ась? А соответственно — обеспеченная именно этими деньгами устойчивость предприятия когда будет больше? Ты не забудь, что покупая, например, решение SAP вкладывают деньги прежде всего в саму SAP AG...

BME>вы также останетесь в выигрыше по крайней мере по количеству выживших нервных клеток

Бабушка надесятеро сказала... увы...

[...]

BME>вы, извиняюсь, директор этого самого предприятия? если нет, то это просто ЭГОИЗМ. уж если хочется разбираться с высокими технологиями, зачем лезть в низкие материи (учетные задачи)? полно задач в науке, технике и т. д. до куда 1С и ей подобные не добрались. там и писать-то интереснее.

BME>по-прежнему готов к потоку КОНСТРУКТИВНОЙ критики

Сделай утверждение — будет и критика. А пока что — эмоциии...

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну, от использования всего этого хозяйства хотя бы для интерфейсов с БД и для коммуникаций с внешним софтом точно никуда не денешься.

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

AVK>>Это сильно зависит от платформы. К примеру в джаве и дотнете эти вопросы уже решены.

ГВ>Хм... ИМХО, GC — это не решение, а закрывание глаз на проблему, точно также, как и Stack Trace по поводу ошибок.

По опыту использования скажу что все таки решение, причем очень неплохое. Это очень здорово — забыть про распределение памяти совсем. Столько гимора снимается. А всякие кеши объектов реализовывать вобще просто несравнимо.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Естественно не все телодвижения IT (я не тебя имею ввиду ) делаются ради моды самой по себе. У Java и у .NET есть свои вполне адекватные области применения. Держаться зубами и ногами за нечто одно-единственное, и на мой взгляд тоже — глупо.

В принципе ты прав, но вот дотнет, а особенно джава стимулируют к тому чтобы большинство задач решать на ней. Т.е. скажем отдельный модуль написать на С++ лучше, но вот при интеграции его в сужествующую джава-среду ты все преимущества потеряешь. Плюс только крупные конторы могут позволить себе держать кодеров для нескольких платформ. В общем вопрос этот очень и очень сложный. Выбирая гетерогенную среду мы в чем то выигрываем, а что то проигрываем. И как всегда приходится искать золотую серидину, а она в каждом случае своя.