Re[5]: Статьи с russian.joelonsoftware.com - Архитектура программного обеспечения

Здравствуйте, 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. Посылать в Яндекс, Апорт и другие поисковые системы, тоже ненадо, все что мог с их помощью достать я достал.

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

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

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

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

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

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

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

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

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

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

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

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

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

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

... << RSDN@Home 1.0 beta 6a >>

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

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

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

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

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. Он, кстати, считает, что если надо, то он всё за две недели возмёт, все эти шарпы и дотнеты, и очень легко избавится от старых стереотипов. Но что-то вот пока никак.

Хех

Ну, с оценкой сроков я в некоторых местах погорячился

Почти сознательно.

А про "две недели" — сам когда-то таким был. Вырос.

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

уважаемый, если хочется сделать (именно сделать, а не ознакомится с технологиями и т.п.) работающую (не находящуюся в стадии разработки, а реально работающую) систему (трехзвенка, 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 если вдвоём.

Кхм ...

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

Здравствуйте, 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 по поводу ошибок.

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

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

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

ГВ>Естественно не все телодвижения IT (я не тебя имею ввиду

) делаются ради моды самой по себе.

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

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

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

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

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

Вот только почему-то ни одна зар-р-раза

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

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

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

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

Решение, конечно, не спорю. И в своём роде очень неплохое, но для технологического ядра, ИМХО, довольно рискованное. А вдруг ему понадобится, например, биллинг или какое-нить управление станками "накрывать"? А это уже реалтайм как-никак... Да и вообще — ядро с непредсказуемыми таймингами...

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

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

Согласен на все сто.

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

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

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

, и сможет наконец снизойти до низких материй — ейной автоматизации.

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

штудирование... — человек черным по-русски написал более менее подробно о своем опыте работы и т.д.

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

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

да много чего еще знаю, уж поверьте...

Резюмируя, предприятие А ТЕРЯЕТ:
1. _a месяцев + сумму $Х (на з/п Команды Разработчиков (КР) + проблемы внедрения)
или
2. _b месяцев + сумму $Y при привлечения конторы (К) специализирующейся на подобных внедрениях.

Именно ТЕРЯЕТ — не надо про добаленную стоимость и т.д. взрослые люди, все понимаем..

(извиняюсь за сложение величин разной размерности

надо сравнить
[(_a месяцев + сумму $Х)+риски1] и [(_b месяцев + сумму $Y)+риски2]

как вот оцените слагаемое <риски1>, при наличие разработчиков уровня автора данной ветки? может быть одного единственного

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

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

ГВ>[...]

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

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

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

утверждение сделано в предудыщей ветке. разумный вариант, имхо, дождаться выхода 8-ки. выходит — в марте 2003. трехзвенка, mssql и т.п.
более продуманная структура бд, в отличии от 7-ки генерит достаточно адекватный sql — сам смотрел, тестировал
при грамотно построенной конфе, на вскидку, на ней 100-200 человек будут работать вольготно.

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

ГВ>Решение, конечно, не спорю. И в своём роде очень неплохое, но для технологического ядра, ИМХО, довольно рискованное. А вдруг ему понадобится, например, биллинг или какое-нить управление станками "накрывать"? А это уже реалтайм как-никак... Да и вообще — ядро с непредсказуемыми таймингами...

Ну значит напишет на С++ внешний компонент, который будет данные буферизировать, а как сервер освободится будет буфер скидывать. Это как писалки CD — жестко реалтаймные устройства, тем не менее в Windows функционируют превосходно.

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

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

ГВ>>Решение, конечно, не спорю. И в своём роде очень неплохое, но для технологического ядра, ИМХО, довольно рискованное. А вдруг ему понадобится, например, биллинг или какое-нить управление станками "накрывать"? А это уже реалтайм как-никак... Да и вообще — ядро с непредсказуемыми таймингами...

AVK>Ну значит напишет на С++ внешний компонент, который будет данные буферизировать, а как сервер освободится будет буфер скидывать. Это как писалки CD — жестко реалтаймные устройства, тем не менее в Windows функционируют превосходно.

Тоже вариант, конечно, но ИМХО, лучше всё-таки наоборот — в ядре сразу максимум критически важных функций реализовать, а что там снаружи — VB, Java, .Net — по вкусу.

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

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

, и сможет наконец снизойти до низких материй — ейной автоматизации.

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

BME>штудирование... — человек черным по-русски написал более менее подробно о своем опыте работы и т.д.

Но тем не менее, он сделал выбор и вобщем-то не просил от него отговаривать. Вероятно, у него тоже есть свои основания так говорить, не находишь? Кстати, ты так и не ответил ничего по поводу "Hello, world".

BME>про добаленную стоимость — слышал. знаю и еще много чего из экономики. например вот знаю о серийном производстве. и о себестоимости серийной продукции так же наслышан. это я к себестоимости серийного специализированного софта (сапы,1с.....)
BME>извиняюсь, но это песни маркетолога.

Ну вот калий с кальцием давай не будем путать. "Серийный софт" и серйиная продукция конвейера — совсем не одно и тоже. И как это соотносится с себестоимостью серийного спецсофта?

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

Верю, верю.

BME>Резюмируя, предприятие А ТЕРЯЕТ:
BME>1. _a месяцев + сумму $Х (на з/п Команды Разработчиков (КР) + проблемы внедрения)
BME>или
BME>2. _b месяцев + сумму $Y при привлечения конторы (К) специализирующейся на подобных внедрениях.

BME>Именно ТЕРЯЕТ — не надо про добаленную стоимость и т.д. взрослые люди, все понимаем..

Речь шла о предприятии-разработчике (или, как я его обозначил — внедренце), это оно получает ДС. Предприятие-клиент, естественно, всегда её оплачивает.

Притом учти, что речь идёт о неизвестном количестве предприятий-клиентов. Соответственно сумма $X будет изменяться абсолютно неизвестно как.

BME>надо сравнить
BME>[(_a месяцев + сумму $Х)+риски1] и [(_b месяцев + сумму $Y)+риски2]

BME>
BME>как вот оцените слагаемое <риски1>, при наличие разработчиков уровня автора данной ветки? может быть одного единственного

Для Украины, плиз. В профайл mvg_first смотрел? Я, например, таких оценок дать не смогу. А тот, кто сможет, уж точно не станет выкладывать их сюда. Увы. Поскольку в первом слагаемом слишком много конкретики, смежной с коммерческой тайной.

BME>утверждение сделано в предудыщей ветке. разумный вариант, имхо, дождаться выхода 8-ки. выходит — в марте 2003. трехзвенка, mssql и т.п.
BME>более продуманная структура бд, в отличии от 7-ки генерит достаточно адекватный sql — сам смотрел, тестировал
BME>при грамотно построенной конфе, на вскидку, на ней 100-200 человек будут работать вольготно.

100-200 человек — это что, потолок? А на какой конфигурации? А кроме mssql она ещё что-нибудь поддерживает? И (самое главное) всем ли охота "укладываться" под 1С?

С другой стороны, может быть, это и разумный выход, но: а) мы не знаем причин, подвигнувших mvg_first на подобное решение, б) он прямо просил не заниматься отговорами. Этих двух причин вполне достаточно, ИМХО, чтобы отвечать по существу заданных вопросов, а не отговаривать от ошибочного по чьему-то мнению решения.

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

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

Давай, извини, не мог удержаться

ГВ>Понимаешь... твои выводы актуальны для тех, кто вынужден принимать условия "как есть".

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

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

Да ладно, я был начальником отдела РПО в России, и, между прочим, подобные вопросы передо мной не стояли. Всё пробовалось, тестилось (преимущественно дома) и потом доказывалось шефу, что так надо. Да и сейчас техническая политика отдела зависит в основном от моих решений, но заниматься такой хренью как "я сказал C++, значит будет C++" я даже и не собираюсь. Более того, любые предложения обсуждаются, взвешиваются и принимается решение об их использовании или неиспользовании в конкретных задачах.

Автору топика я могу сказать, что его затея гарантированно обречена на провал, именно по причине не гибкости подхода и ориентации на древние технологии. Он просто не представляет себе с его "средним уровнем", что такое в дебагере на плюсах три дня искать мемори-лики или утечку других ресурсов. О какой вообще системе предприятия с нуля идёт речь? Детский сад, ей богу. Это всё уже было пройдено 8-10 лет назад целым поколением программистов. И где все те чудо-универсальные системы? Везде, ну почти везде, стоит 1С.

Если у него и есть шанс, то только один, постепенно, без революций, заменять части системы, обеспечивая при этом интеграцию с существующим ПО. Любой другой вариант — авантюра в чистом виде.

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

ГВ>Естественно не все телодвижения IT (я не тебя имею ввиду

) делаются ради моды самой по себе.

Не проблема, я могу прикинуть свой опыт с самого начала.

Мои первые проекты были очень длинные, дело было в НИИ и мы годами занимались научными, блин, исследованиями. Спутники в космос запускали, топили их сотнями в Тихом и других океанах, делали свои компиляторы и языки имитационного моделирования. Классно было, опыт как разработчика неоценимый. Только одна проблема, все 100% тех задач которые мы делали пошли в мусорку.

Дальше был период тех самых бухгалтерий. Свою с нуля, а как же иначе? 1С тогда ешё из пелёнок не вылезла, а у нас уже был рабочий комплексный прототим для целого предприятия. На доводку правда ушли годы, но зато на этой базе мы наклепали кучу других проектов. Правда не всегда удачных, часть тоже шла в мусорку или с большими задержками (!) и затратами на внедрение. Проекты эти были длинной уже не более года. Процент внедрения можно оценить примерно в 75%, что я считаю большим достижением.

Параллельно мы продолжали кое-что делать для военных, и вот интересно, что чем длиннее были этапы, тем труднее было их завершить и получить свои кровные. Последняя такая затея как мне известно так и не удалась. Процент успеха можно оценить как — 50%.

Были конечно и проекты, которые с самого начала были обречены на успех, т.к. в противном случае, нам бы просто не сносить головы. И что интересно, внедрялись они почти в срок, но в очень сыром виде и доводились потом до ума по ходу дела, чем и был обеспечен успех, хотя мы нагло требовали ещё 6 месяцев и считали, что поступаем против всех правил.

Сейчас (исключая конечно клинические случаи, описанные мной в предыдущем посте) процент внедрения всех задач у нас 100%. И я считаю, что это обеспечивается прежде всего коротким циклом разработки.

Так что насчёт обобщения частного опыта ты возможно не совсем прав. Java, .NET и вообще новые технологии позволяют сократить время разработки в разы, следовательно (из моей теории

) таким проектам обеспечен успех по определению.

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

ГВ>Тоже вариант, конечно, но ИМХО, лучше всё-таки наоборот — в ядре сразу максимум критически важных функций реализовать, а что там снаружи — VB, Java, .Net — по вкусу.

Слишком дорогим может оказаться написание ядра с заточкой под реалтайм задачи. Если это сервер для управления предприятием то такие задачи там скорее исключение чем правило.

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

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

ГВ>Но тем не менее, он сделал выбор и вобщем-то не просил от него отговаривать. Вероятно, у него тоже есть свои основания так говорить, не находишь?

Вот только он об этих основаниях пока не признался.

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

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

ГВ>100-200 человек — это что, потолок? А на какой конфигурации? А кроме mssql она ещё что-нибудь поддерживает? И (самое главное) всем ли охота "укладываться" под 1С?

ГВ>С другой стороны, может быть, это и разумный выход, но: а) мы не знаем причин, подвигнувших mvg_first на подобное решение, б) он прямо просил не заниматься отговорами. Этих двух причин вполне достаточно, ИМХО, чтобы отвечать по существу заданных вопросов, а не отговаривать от ошибочного по чьему-то мнению решения.

уважаемый. если интересно описание 1С как платформы, расскажу. по поводу просьбы автора ветки не заводить разговор в сторону так же помню. думаю его проблемы, которые были на 7-ой 1С, в большинстве своем исчезнут на 8-ке. но его изначальная постановка вопроса (что почитать, чтобы по-быстрому налабать АСУ предприятия, так вроде?) вызвала у меня просто испуг

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

BME>уважаемый. если интересно описание 1С как платформы, расскажу.

Интересно, расскажи. Если хочешь — приватом.

BME>по поводу просьбы автора ветки не заводить разговор в сторону так же помню. думаю его проблемы, которые были на 7-ой 1С, в большинстве своем исчезнут на 8-ке. но его изначальная постановка вопроса (что почитать, чтобы по-быстрому налабать АСУ предприятия, так вроде?) вызвала у меня просто испуг

Ну, вообще-то он немного о другом спрашивал.

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

ГВ>>Понимаешь... твои выводы актуальны для тех, кто вынужден принимать условия "как есть".

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

Не без того.

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

IT>Да ладно, я был начальником отдела РПО в России, и, между прочим, подобные вопросы передо мной не стояли.

Ну, из этого ровным счётом ничего не следует, кроме того, что перед тобой такие вопросы не стояли...

IT>Всё пробовалось, тестилось (преимущественно дома) и потом доказывалось шефу, что так надо.

...то есть, они стояли перед твоим шефом, только и всего.

IT>Да и сейчас техническая политика отдела зависит в основном от моих решений, но заниматься такой хренью как "я сказал C++, значит будет C++" я даже и не собираюсь. Более того, любые предложения обсуждаются, взвешиваются и принимается решение об их использовании или неиспользовании в конкретных задачах.

А если конкретная задача может быть сформулирована как разработка АСУ "с нуля"? Знаешь, я не очень верю в полезность обсуждений выбора того или иного решения, особенно когда техническое решение принимается большинством голосов — большинство, как известно... 1000000 lemmings cann't be wrong. Наверное.

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

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

IT>Он просто не представляет себе с его "средним уровнем", что такое в дебагере на плюсах три дня искать мемори-лики или утечку других ресурсов.

Ну, а мы на что? Подскажем как делать так, чтобы ликов не было. Вообще. Кроме того, он и сам сможет спецов у себя поискать.

IT>О какой вообще системе предприятия с нуля идёт речь? Детский сад, ей богу. Это всё уже было пройдено 8-10 лет назад целым поколением программистов. И где все те чудо-универсальные системы? Везде, ну почти везде, стоит 1С.

Ну во-первых, не одна только 1С, а во-вторых, сейчас всё равно пойдёт очередная волна собственных разработок. Слишком уж жирный кусок — автоматизация, чтобы на нём могла остаться только 1С.

Его затея, ИМХО, будет обречена на провал при отсутствии заказчиков, понимающих хотя бы — что им нужно. Ещё его затея гарантированно провалится, если начнутся внутрикорпоративные разборки — такие проекты "режут" обычно в первую очередь.

IT>Если у него и есть шанс, то только один, постепенно, без революций, заменять части системы, обеспечивая при этом интеграцию с существующим ПО. Любой другой вариант — авантюра в чистом виде.

Ты наверное, не представляешь, но в СНГ ещё навалом случаев, когда на предприятиях нет вообще никакой автоматизации. Соответственно, интегрироваться там попросту не с чем. Ну, может быть, не считая 1С:Бухгалтерии.

IT>Не проблема, я могу прикинуть свой опыт с самого начала.

Если честно, то я думал, что ветка на этом и закончится. Ну ладно...

IT>Мои первые проекты были очень длинные, дело было в НИИ и мы годами занимались научными, блин, исследованиями. Спутники в космос запускали, топили их сотнями в Тихом и других океанах, делали свои компиляторы и языки имитационного моделирования. Классно было, опыт как разработчика неоценимый. Только одна проблема, все 100% тех задач которые мы делали пошли в мусорку.

Как я понимаю, они пошли в мусорку а) как и немалая часть исследовательских работ и б) вместе с космической индустрией СССР. Не так?

IT>Дальше был период тех самых бухгалтерий. Свою с нуля, а как же иначе? 1С тогда ешё из пелёнок не вылезла, а у нас уже был рабочий комплексный прототим для целого предприятия. На доводку правда ушли годы, но зато на этой базе мы наклепали кучу других проектов. Правда не всегда удачных, часть тоже шла в мусорку или с большими задержками (!) и затратами на внедрение. Процент внедрения можно оценить примерно в 75%, что я считаю большим достижением.

Да, действительно — неплохо. Хотя, сталкивался я с плодами трудов выходцев из НИИ (снова, я не тебя имею ввиду)... ну как тебе сказать... наверное, это неизлечимо.

Всё что можно сказать о плохом стиле — это кним. Хотя мужики умные. Хотя и трусливые нередко.

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

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

IT>Параллельно мы продолжали кое-что делать для военных, и вот интересно, что чем длиннее были этапы, тем труднее было их завершить и получить свои кровные. Последняя такая затея как мне известно так и не удалась. Процент успеха можно оценить как — 50%.

Ты не забудь, что всё это происходило на фоне снижения финансирования военных в целом. Да и другие факторы были, если, конечно, речь идёт об СССР-СНГ. Даты ты не проставил, место действия — тоже, ну да ладно.

IT>Были конечно и проекты, которые с самого начала были обречены на успех, т.к. в противном случае, нам бы просто не сносить головы. И что интересно, внедрялись они почти в срок, но в очень сыром виде и доводились потом до ума по ходу дела, чем и был обеспечен успех, хотя мы нагло требовали ещё 6 месяцев и считали, что поступаем против всех правил.

IT>Сейчас (исключая конечно клинические случаи, описанные мной в предыдущем посте) процент внедрения всех задач у нас 100%. И я считаю, что это обеспечивается прежде всего коротким циклом разработки.

А может, всё дело в том, что класс задач изменился? Задачи стали более мелкими. Их лучше понимает и заказчик и вы. Отсюда и неизбежный в таких случаях успех внедрения. Ты ведь никак не характеризуешь сами задачи.

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

) таким проектам обеспечен успех по определению.

Уффф... Ужас. Ну давай по-новой — какие задачи? Как решены? Хочешь, подкину ещё несколько вопросов по которым я оцениваю качество разработки? Слепить ИС на коленке может любой, а вот, например, решить задачи ограничения доступа более детально, чем это предоставляет сервер БД или хуже того — базовая ОС, или, например, оптимизации структуры БД "на ходу" — почти никто. Точно также, как почти никто, например, не может решить задачу вывода мультиструктурных списков (это такие, где для разных записей разные наборы колонок), да элементарно зачастую не могут преположить, что дерево, к примеру, может быть совмещено со списком.

В принципе, частично с тобой согласен — долгострой по большому счёту всех участников только раздражает. А короткие сроки в основном появляются при ясности задач (они ещё могут быть при адекватной интерпретации задачи, но это сильно зависит от людей, а о людях я уже писал). Но знаешь... если продолжить твою теорию, то получится, что чинить сапоги всяко выгоднее, чем строить заводы по производству тех же сапог. Ан ведь находятся же ещё те, кто такие заводы строит. Просто это разные сегменты рынка и требуют, соответственно, разных подходов. Тебе оказался адекватен подход сапожника (не сочти это попыткой оскорбления, пожалуйста), mvg_first хочет строить завод. Чуешь разницу? Сапожник не рекомендует строить завод... звучит сильно. Ты пойми, что если ты нашёл для себя определённую нишу — то это супер, это здорово, но для другого она может быть другой. Так было есть и пребудет ныне и присно и во веки веков. Я не пытаюсь сказать, что твой опыт мелок и неприятен и прочую чушь. Наоброт, мне очень интересно было прочесть твой постинг, возможно, ты Мастер в свой области. Нет проблем. Но почему ты (кстати, не ты один) пытаешься другим запретить делать то, на что они имеют полное право и более того — то, чего они хотят?

Так что, всё, что ты сейчас доказал, так это, по крайней мере не-ложность моего утверждения о неуместности обобщения частного опыта. Увы. Кроме того — непосредственно подтвердил мои предположения о необходимости для mvg_first противостояния внешненму давлению. Вот смотри, мы с тобой потратили без малого полдня на бесплодную в сущности дискуссию. А у него таких (и ещё похлеще) споров будет вагон и мелкая телега, а ещё нужно думать. А думать-то может оказаться и некогда. И вот тогда действительно появится ещё один камешек в почву для мифов о безнадёжных проектах. Вот так-то.

Так что, извини, но:
Мораль сей басни такова — сто зайцев вместе п$#&%т льва... Только вот львами они от этого не станут...

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

ГВ>>Тоже вариант, конечно, но ИМХО, лучше всё-таки наоборот — в ядре сразу максимум критически важных функций реализовать, а что там снаружи — VB, Java, .Net — по вкусу.

AVK>Слишком дорогим может оказаться написание ядра с заточкой под реалтайм задачи. Если это сервер для управления предприятием то такие задачи там скорее исключение чем правило.

Тоже согласен, но зачем создавать лишнюю почву для архитектурной эклектики? А с компактным и быстродействующим сервером он сможет и другие, в частности — более мелкие рынки накрыть. Desktop-ы ьам всякие, мелкие предприятия. Хотя тут уже, конечно, не от сервера всё зависит.

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

ГВ>>Но тем не менее, он сделал выбор и вобщем-то не просил от него отговаривать. Вероятно, у него тоже есть свои основания так говорить, не находишь?

AVK>Вот только он об этих основаниях пока не признался.

Ну что же... подождём. Глядишь и выяснится чего.

То-то он обрабуется, завидев флейм, вызванный его вопросом.

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

IT>>Да ладно, я был начальником отдела РПО в России, и, между прочим, подобные вопросы передо мной не стояли.

ГВ>Ну, из этого ровным счётом ничего не следует, кроме того, что перед тобой такие вопросы не стояли...

Да, вот такие вопросы передо мной не стояли

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

IT>>Всё пробовалось, тестилось (преимущественно дома) и потом доказывалось шефу, что так надо.

ГВ>...то есть, они стояли перед твоим шефом, только и всего.

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

ГВ>А если конкретная задача может быть сформулирована как разработка АСУ "с нуля"?

Это не задача, это большой долгосрочный проект.

ГВ>Знаешь, я не очень верю в полезность обсуждений выбора того или иного решения, особенно когда техническое решение принимается большинством голосов — большинство, как известно... 1000000 lemmings cann't be wrong. Наверное.

Напрасно не веришь. Обсуждение и вообще коммуникация один из основных факторов эффективности работы команды. Ты не поверишь, но решения принимаются всегда единогласно, именно потому, что им предшествует детальное обсуждение.

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

ГВ>Да ну! Подход то максимально гибок, просто ему практически мало есть на что опереться из готовых квазитехнологий.

Перечитай его сообщение ещё раз:

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

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

Максимальная гибкость так и прёт

IT>>Он просто не представляет себе с его "средним уровнем", что такое в дебагере на плюсах три дня искать мемори-лики или утечку других ресурсов.

ГВ>Ну, а мы на что? Подскажем как делать так, чтобы ликов не было. Вообще. Кроме того, он и сам сможет спецов у себя поискать.

Ты ему лучше подскажи как этого совсем избежать, у него же планы пахать не перепахать, когда ему в дебагере сидеть лики ловить?

IT>>О какой вообще системе предприятия с нуля идёт речь? Детский сад, ей богу. Это всё уже было пройдено 8-10 лет назад целым поколением программистов. И где все те чудо-универсальные системы? Везде, ну почти везде, стоит 1С.

ГВ>Ну во-первых, не одна только 1С, а во-вторых, сейчас всё равно пойдёт очередная волна собственных разработок. Слишком уж жирный кусок — автоматизация, чтобы на нём могла остаться только 1С.

Возможно, даже скорее всего так и будет.

ГВ>Его затея, ИМХО, будет обречена на провал при отсутствии заказчиков, понимающих хотя бы — что им нужно.

Как я понял он собирается ставить эксперименты на собственной конторе. Писать без заказчика подобную систему — это тем более утопия.

ГВ>Ещё его затея гарантированно провалится, если начнутся внутрикорпоративные разборки — такие проекты "режут" обычно в первую очередь.

Ну это и ёжику понятно.

IT>>Если у него и есть шанс, то только один, постепенно, без революций, заменять части системы, обеспечивая при этом интеграцию с существующим ПО. Любой другой вариант — авантюра в чистом виде.

ГВ>Ты наверное, не представляешь, но в СНГ ещё навалом случаев, когда на предприятиях нет вообще никакой автоматизации. Соответственно, интегрироваться там попросту не с чем. Ну, может быть, не считая 1С:Бухгалтерии.

Вот с ней и интегрировать, тем более что автор топика именно о ней и говорил.

ГВ>Как я понимаю, они пошли в мусорку а) как и немалая часть исследовательских работ и б) вместе с космической индустрией СССР. Не так?

В том числе. Но то, что это проекты неживые было видно ещё при их разработки.

ГВ>Да, действительно — неплохо. Хотя, сталкивался я с плодами трудов выходцев из НИИ (снова, я не тебя имею ввиду)...

У меня складывается впечатление, что имеешь.

ГВ>ну как тебе сказать... наверное, это неизлечимо.

Всё что можно сказать о плохом стиле — это кним. Хотя мужики умные. Хотя и трусливые нередко.

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

ГВ>Кроме того, знаешь... Я сам бывал в подобных ситуациях и меня удивляло вот что. Всегда, ну почти всегда неудачи внедрения списывались тем или иным образом на заказчика. Никто, то есть, вообще никто не пытался строить индукцию на тему — что же нам сделать, чтобы избежать подобных ситуаций в принципе. Ну я вот пытался... А как бесились, когда заказчику хотелось передвинуть контрол на экране или получалось, что поле добавить нужно... Просто шекспировские страсти!

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

ГВ>По-моему, основная проблема нашей индустрии связана с тем, что в ней стремительно уменьшается процент людей, способных строить индукцию. Если им сказать, что есть красный кирпич, синий камень и белый камень, то они никогда даже не подумают, что может появиться белый кирпич или, скажем, жёлтый камень... Точно также, они никогда ни на йоту не предполОжат возможных изменений продукта и требований заказчика. Вот это я и называю обычно интеллектуальной трусостью. И к сожалению, в околоакадемической среде таких — до той самой матери, а в не академической — в десять раз больше.

Это ты опять на меня намекаешь?

ГВ>Ты не забудь, что всё это происходило на фоне снижения финансирования военных в целом. Да и другие факторы были, если, конечно, речь идёт об СССР-СНГ. Даты ты не проставил, место действия — тоже, ну да ладно.

Военные находились (да и сейчас наверное там же) в Москве, разве в России военные где-то ещё занимаются софтом?

IT>>Сейчас (исключая конечно клинические случаи, описанные мной в предыдущем посте) процент внедрения всех задач у нас 100%. И я считаю, что это обеспечивается прежде всего коротким циклом разработки.

ГВ>А может, всё дело в том, что класс задач изменился?

Естественно изменился, действие теперь происходит на другом континенте

ГВ>Задачи стали более мелкими. Их лучше понимает и заказчик и вы. Отсюда и неизбежный в таких случаях успех внедрения. Ты ведь никак не характеризуешь сами задачи.

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

ГВ>Уффф... Ужас. Ну давай по-новой — какие задачи? Как решены?

А о чём мы вообще говорим?

ГВ>Хочешь, подкину ещё несколько вопросов по которым я оцениваю качество разработки? Слепить ИС на коленке может любой, а вот, например, решить задачи ограничения доступа более детально, чем это предоставляет сервер БД или хуже того — базовая ОС,

Естественно решено, с системой работает около 1000 employee, без разграничений прав доступа и секурити никак. Но решение не вполне устраивает, поэтому будет пересматриваться.

ГВ>или, например, оптимизации структуры БД "на ходу" — почти никто.

К сожалению это приходится делать, так как нам досталось наследие от консультантов, которые лепили как могли (наверное работали когда-то в тех НИИ, о которых ты упоминал). До сих пор это делалось по мелочёвки, но структура базы уже не удовлетворяет потребностям. План миграции уже определён и решено, что резать будем по живому. Т.е. менять структуру базы, корректировать софт прямо на рабочей системе без всяких "переделать всё нах..". Жуть конечно, но это единственный способ, возможный во многом, кстати, благодаря наличию сервера приложений.

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

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

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

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

Это зависит от задачи. Если требуется строить завод, то будем строить завод, если нужно чинить сапоги, то зачем строить завод, что бы починить один сапог.

ГВ>Ан ведь находятся же ещё те, кто такие заводы строит.

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

ГВ>Просто это разные сегменты рынка и требуют, соответственно, разных подходов. Тебе оказался адекватен подход сапожника (не сочти это попыткой оскорбления, пожалуйста)

Счёл

ГВ>, mvg_first хочет строить завод. Чуешь разницу?

Я чую чем это попахивает, обычное шапкозакидательство.
Вот ты как почётный заводостроитель, объясни ему, да и нам сапожникам, через что ему придётся пройти без опыта, без знаний, без понимания того, что ему нужно делать. Судя по его сообщению, ему самому просто нужно поучить C++ и COM, так как он где-то услышал, что это круто. На самом же деле этот поезд уже давно ушёл и сейчас это совсем не круто. Через пол года он прочитает про .NET и захочет всё перекосить по новой. Вот это я чую.

ГВ>Сапожник не рекомендует строить завод... звучит сильно.

Да, сильно. Если бы я не был такой добрый, то я бы точно обиделся. Сапожником меня ещё никто не обзывал, ну да ладно, видимо и ты и mvg_first очень крутые заводостроители и нам деревенским ни чета

ГВ>Ты пойми, что если ты нашёл для себя определённую нишу — то это супер, это здорово, но для другого она может быть другой.

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

ГВ>Так было есть и пребудет ныне и присно и во веки веков. Я не пытаюсь сказать, что твой опыт мелок и неприятен и прочую чушь.

Да ладно, Ты не не пытаешься, ты это делаешь

ГВ>Наоброт, мне очень интересно было прочесть твой постинг, возможно, ты Мастер в свой области. Нет проблем. Но почему ты (кстати, не ты один) пытаешься другим запретить делать то, на что они имеют полное право и более того — то, чего они хотят?

Я кому-то что-то запрешал? Перечитай топик ещё раз, я, кажется, автору первым посоветовал взять ATL, COM, MFC и вперёд, если уж он так хочет позаниматься мазахизмом за денежки своей конторы.

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

Только пусть не переусердствует, а то превратиться не дай бог из начальника в старшего девелопера в лучшем случае

ГВ>Мораль сей басни такова — сто зайцев вместе п$#&%т льва... Только вот львами они от этого не станут...

А это ты к чему? Извини, тупею на чужбине.

Здравствуйте, IT:

Слушай, давай мы с тобой эту ветку завяжем, а то чует моё сердце — неладно это кончится. Поскольку мы уже начинаем соскальзывать на личности.

Относительно же шага mvg_first скажу, что это в конце концов его личное дело и не факт, что всё, что мы тут с тобой наговорили сможет ему в какой-то степени помочь. Хотя я лично постараюсь не отказывать по существу.

IT, насколько я заметил, ты иногда выставляешь личный опыт в публичной конференции, а потом обижаться на оценку его уместности. Не хочешь нелицеприятных оценок — деперсонифицируй свои посылки, и никто в обиде не будет. Чего же проще?

Так что: а) вот абсолютно честно — когда я говорил о выходцах из НИИ и проч. я имел ввиду людей не связанных с тобой ни малейшим образом, б) я понимаю всю внешнюю двусмысленность моих сравнений но опять-таки, унизить тебя персонально не пытался, так что если тебе угодно — обижайся, конечно, но повторюсь, что тебя персонально задевать я никоим образом не собираюсь, в) относительно сапожника — извини коль принял это за скрытое оскорбление, поскольку я просто употребил то сравнение, которое показалось адекватным, отнюдь не желая тебя оскорблять.

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

Но тем не менее, всё же благодарен тебе за дискуссию (которая, кстати, содержала не совсем приятные нотки и для меня тоже) и не откажусь от обсуждения технических и иных существенных аспектов вопроса mvg_first.

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

ГВ>Слушай, давай мы с тобой эту ветку завяжем, а то чует моё сердце — неладно это кончится. Поскольку мы уже начинаем соскальзывать на личности.

Завязываем.

ГВ>IT, насколько я заметил, ты иногда выставляешь личный опыт в публичной конференции, а потом обижаться на оценку его уместности. Не хочешь нелицеприятных оценок — деперсонифицируй свои посылки, и никто в обиде не будет. Чего же проще?

Не вижу ничего постыдного в своём опыте

Но, ты прав, не стоит публично его анализировать, некоторые к этому относятся не вполне адекватно.

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

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

BME>>уважаемый. если интересно описание 1С как платформы, расскажу.

ГВ>Интересно, расскажи. Если хочешь — приватом.

да ладно уж. может кому еще будет интересно.
http://klerk.ru/soft/1c/?916 — статья старая, но информация в ней подтвержденная. все так и есть
из "революционного"

:
— привели в удобоворимый вид структуру бд — отказались от общих таблиц (общий журнал, константы). теперь как проектировщик конфы пользователей по табличкам разведет, так и будет. (1-я беда 7-ки)
— генеримый sql стал куда более вразумительный и компактный (2-я беда 7-ки)
— наваяли собственный app server, который будет синглюзером работать с mssql. пока объявили только о поддержке mssql 2000. про поддержку оракла и прочих серверов я задавал вопрос на семинаре разработчикам, говорят пока не планируют, да и смысла большого не видят. без коментариев.
— наваяли собственный формат бд (файл-серверная версия). дюже шустрый. по тестам обходит современную дбф-версию 7-ки в 7-8 раз на идентичных задачах. это вариант "для бедных" — на небольшое количество пользователей.
— из разряда "вишек", но тем не менее: не используют виндовую графику — написали свое — вполне презентабельно выглядит.
— в язык ввели кучу полезных фич. вообще, даже на уровне языка оптимизировали обращение к бд (отдельные объекты на чтение, отдельные на запись и т.д.). собственный (1с) язык запросов стал максимально приближен к sql.
— поддержка unicode'а. интерфейсы можно элементарно делать на нескольких языках
— поддержка ole

имхо, на эта платформа реально сможет конкурировать со многими erp-системами (и нашими и не нашими). но, учитывая огромное количество разработчиков (по неофициальным данным в СНГ их около 100.000), простоту и мощность языка, скорость разработки, цену (ее, правда, пока не оглашали), она скорее всего станет стандартом разработки эконом. прложений в ближайшие несколько лет на рынке не очень крупных предприятий по крайней мере в РФ. громко конечно сказано

, но скорее всего так и будет — люди всегда стараются экономить время и деньги, а 1с это как раз и позволяет.

BME>>по поводу просьбы автора ветки не заводить разговор в сторону так же помню. думаю его проблемы, которые были на 7-ой 1С, в большинстве своем исчезнут на 8-ке. но его изначальная постановка вопроса (что почитать, чтобы по-быстрому налабать АСУ предприятия, так вроде?) вызвала у меня просто испуг

ГВ>Ну, вообще-то он немного о другом спрашивал.

да вот не показалось что-то. конечная его цель, имхо, именно такая

Здравствуйте, Аноним, Вы писали:

А>да ладно уж. может кому еще будет интересно.

OK, спасибо за ссылку.

А>имхо, на эта платформа реально сможет конкурировать со многими erp-системами (и нашими и не нашими). но, учитывая огромное количество разработчиков (по неофициальным данным в СНГ их около 100.000), простоту и мощность языка, скорость разработки, цену (ее, правда, пока не оглашали), она скорее всего станет стандартом разработки эконом. прложений в ближайшие несколько лет на рынке не очень крупных предприятий по крайней мере в РФ. громко конечно сказано

, но скорее всего так и будет — люди всегда стараются экономить время и деньги, а 1с это как раз и позволяет.

Всё могет быть. С некоторой вероятностью.

BME>>>по поводу просьбы автора ветки не заводить разговор в сторону так же помню. думаю его проблемы, которые были на 7-ой 1С, в большинстве своем исчезнут на 8-ке. но его изначальная постановка вопроса (что почитать, чтобы по-быстрому налабать АСУ предприятия, так вроде?) вызвала у меня просто испуг

ГВ>>Ну, вообще-то он немного о другом спрашивал.

А>да вот не показалось что-то. конечная его цель, имхо, именно такая

Ну уж, что показалось — то показалось.

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

BME>думаю его проблемы, которые были на 7-ой 1С, в большинстве своем исчезнут на 8-ке.

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

... << RSDN@Home 1.0 beta 6a (developer build)>>

Здравствуйте, <Аноним>, Вы писали:

А>- наваяли собственный формат бд (файл-серверная версия). дюже шустрый. по тестам обходит современную дбф-версию 7-ки в 7-8 раз на идентичных задачах. это вариант "для бедных" — на небольшое количество пользователей.

Не из-за собственного формата он в 7-8 раз обходит, а из-за отсутствия безумно тупых блокировок. Сам ведь написал — нет теперь общих таблиц, потому и такое ускорение.

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

Чего? Как это не используют виндовую графику? Они что — через DirectDraw на экран что ли выводят?

А>- поддержка ole

А то ее не было.

А>имхо, на эта платформа реально сможет конкурировать со многими erp-системами (и нашими и не нашими).

Вот когда они конфигурации под нее нормальные напишут, тогда и сможет. А пока что это концепт, не более того.

... << RSDN@Home 1.0 beta 6a (developer build)>>

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

ГВ>Тоже согласен, но зачем создавать лишнюю почву для архитектурной эклектики? А с компактным и быстродействующим сервером он сможет и другие, в частности — более мелкие рынки накрыть. Desktop-ы ьам всякие, мелкие предприятия. Хотя тут уже, конечно, не от сервера всё зависит.

Помнишь с чего разговор начался? С замены 1С.

... << RSDN@Home 1.0 beta 6a (developer build)>>

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

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

Целиком и польностью поддерживаю это мнение

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

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

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

Именно по этому я хочу выбрать только один язык и только одну платформу. А то что я указывал возможные способы разработки на других языках и средах, так это потому что — в последствии навернякак найдутся герои возжелающие дорабатывать систему моей фирмы, и будут верещать от того что их ЛЮБИМАЯ и УНИВЕРСАЛЬНАЯ JAVA не может использовать мою "убожищную" разработку. Мне так же приходится думать и о том что мою разработку нужно будет продавать (по крайней мере я очень на это надеюсь) а не топить в тихом океане и не выбрасывать в мусорку.

Основная моя проблема — это выбрать какой язык или способ автоматизации изучать услиенно. У меня нет возможности и средств, набрать 10 человек и изучать одновременно JAVU, C# и прочие языки — потому что это все время. Когда же создавать систему. При том наличии вразумительной литературы объясняющей как разрабатывать (а не как двигать мышкой по экрану) — выучить указанные языки до уровня на котором можно будет создать систему, я думаю просто невозможно, когда это случиться — они в свою очередь станут мертвыми языками.\

Поэтому я и пытаюсь выучить один из устаревших но мощных языков. Который переживет кого угодно (по моим оценкам)

Учат же медики латынь — в конце концов.

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

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

BME>>думаю его проблемы, которые были на 7-ой 1С, в большинстве своем исчезнут на 8-ке.

AVK>К сожалению одна из основных проблем — невозможность нормальной групповой разработки и отсутствие контроля версий не исчезла. А всего то надо было дать возможность сохранять конфигурацию в текстовом виде.

с этим не могу не согласиться. вещь действительно нужная.
правда, есть маленький контраргумент — конфы пишутся маленькими коллективами (1-5 человек). даже очень серьезные: об ИТРП слышали. так вот 5 человек трудится. типовые 1с-е конфы вообще пишут по 1-м — 2-мя разработчиками.

вообщем, разумеется 1С не есть панацея и спасение человечества, я об этом не говорю.
заговорил же я о ней ТОЛЬКО в контексте высказывания автора. как говорится "кесарю — кесарево, а слесарю — слесарево". никого не хочу обидеть.

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

IT>Я чую чем это попахивает, обычное шапкозакидательство.
IT>Вот ты как почётный заводостроитель, объясни ему, да и нам сапожникам, через что ему придётся пройти без опыта, без знаний, без понимания того, что ему нужно делать. Судя по его сообщению, ему самому просто нужно поучить C++ и COM, так как он где-то услышал, что это круто. На самом же деле этот поезд уже давно ушёл и сейчас это совсем не круто. Через пол года он прочитает про .NET и захочет всё перекосить по новой. Вот это я чую.

Я уже давно прочитал и про COM и про нет. И мало того даже конкретно его применял. И то что поезд Микрософта уже давно мимо него проехал и забыл я тоже понимаю

ГВ>>Сапожник не рекомендует строить завод... звучит сильно.

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

Я так понимаю сидишь ты где нибудь в БАЛЬШУШЕЙ конторе в которой кто-то за тебя очень давно выбрал стратегию работы а тебе только говорят в какую сторону копать, и сомневаюсь что ты толком сталкивался с проблемой которую предстоить решить мне. (может я ее некорретно выразил — но она такова, определитmcя с платформой на которой создавать систему автоматизации, при наличии штата программистов в 3-человека, у которых объем знаний — 1С не более. При том что начальство желает занять нишу поставщиков корпоративных АСУ в городе.)

Что мне посоветушеь ответить руководству (котору кстати совершенно пофигу на чем я буду писать — хоть на ассемблере или даже на перфокартах) им важен результат. А я им скажу понимаете тут некий господин IT советует забить на все это потому что мы не потянем и все тут. Потому что мы пытаемся ехать на отсталых технологиях, а если начнем учить мнодные технологии — пройдет время и они поять станут отсталыми. Так что ли?

Или может ты хочешь сказать что изучить JAVU С# и другие языке получиться быстрее чем изучить VC. А единственное тове мнение что я буду сидеь за дебаггером и ловить мемори-лики то что-то мнея берето соменение что Джава такая уж безгрешная.

Есть одна поговорка "Шож если они такие умные — то помему они строем не ходят?". Что то я не заметил что бы AXAPTA например была написана на джаве или та же 1С например?

И кстати клиенту у меня есть, и даже не одни. И я точно знаю что 1С — им не нужна

А если ты на чужбине то пожалйста не путай подходы ихние с нашими

Они разные и очень на много.

Тот же заказчик например. Пришел ко мне и говорит мне нужна система. А я начитавшись разумных книшежек (О RUP и схожих с ними процессах) думаю, спросить у него чего нибудь или сразу сказать — будет сделано. Но по лицу видно что он нифига не знает как должна функционировать система. У нас до сих пор заказчики заказывает системы из престихных соображений а не для улучшения учета или еще чего то там

Извните за очепятки

Спшил выразить мысль. Я думаю вы поняли что я хотел сказать.

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

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

С ним уже заканчивать надо (естественно, это ИМХО).

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

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

ГВ>>Но тем не менее, он сделал выбор и вобщем-то не просил от него отговаривать. Вероятно, у него тоже есть свои основания так говорить, не находишь?

AVK>Вот только он об этих основаниях пока не признался.

Да что там основания

Одни эмоции и интуиция

Но нетолько еще потому что:

1. Внедренцев 1С -у нас в городе выше крыши. И исправление их ошибок меня уже достатет

2. На VC (или скажем так С++) можно написать как низкоуровневую задачу, так и задачу бизнеслогики, Т.е. язык достаточно гибкий (хотя и сложный в освоении, но как говорил всем известный человек: "тяжело в учении — легко в бою")
3. Я в данный момент услиенно изучаю ООАП (объектно ориентированное проектирование) и CASE технологии а в них как то мало кто приводит примеры на 1С, DELPHI, но очень много примеров на VC, хотя и на джаве конечно. Но Джаву нехочу — она как и C# сильно привязана к платформе на которой летает

Хотя это только мое мнение — но все равно нехочу (и давайте не будем спорить хороша она ли и плоха)

Ну и просто, особое мнение — чем тажелее труд тем больше внимательности — ато так, не заботимся о памяти? — во как класно сюда 100К туда 100К в результате скорость в дауне памяти нехватает

Опять же это сугубо моя точка зрения и все тут

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

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

ГВ>>>Но тем не менее, он сделал выбор и вобщем-то не просил от него отговаривать. Вероятно, у него тоже есть свои основания так говорить, не находишь?

AVK>>Вот только он об этих основаниях пока не признался.

ГВ>Ну что же... подождём. Глядишь и выяснится чего.

То-то он обрабуется, завидев флейм, вызванный его вопросом.

Да уж обрадовался

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

ГВ>>Ну во-первых, не одна только 1С, а во-вторых, сейчас всё равно пойдёт очередная волна собственных разработок. Слишком уж жирный кусок — автоматизация, чтобы на нём могла остаться только 1С.

IT>Возможно, даже скорее всего так и будет.

Ну не знаю насчет собственных разработок...
Ведь полно уже — Axapta, Scala.
Да и SAP уже пытается "облегченные" версии своих продуктов выпускать для средних предприятий.
И все они на слуху.

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

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

ГВ>>100-200 человек — это что, потолок? А на какой конфигурации? А кроме mssql она ещё что-нибудь поддерживает? И (самое главное) всем ли охота "укладываться" под 1С?

ГВ>>С другой стороны, может быть, это и разумный выход, но: а) мы не знаем причин, подвигнувших mvg_first на подобное решение, б) он прямо просил не заниматься отговорами. Этих двух причин вполне достаточно, ИМХО, чтобы отвечать по существу заданных вопросов, а не отговаривать от ошибочного по чьему-то мнению решения.

BME>уважаемый. если интересно описание 1С как платформы, расскажу. по поводу просьбы автора ветки не заводить разговор в сторону так же помню. думаю его проблемы, которые были на 7-ой 1С, в большинстве своем исчезнут на 8-ке. но его изначальная постановка вопроса (что почитать, чтобы по-быстрому налабать АСУ предприятия, так вроде?) вызвала у меня просто испуг

Уважаемый BME я "не первый год замужем"

И знаю что АСУ вопервых — не "лабаются", а во вторых не "побыстрому". И свою систему (т.е. ту которую собираюсь создавать) обдумываю и проектирую уже достаточно таки давно. Но пока в концептуальном плане, безотносительно к языку реализации. А этот топик затеял для того что бы мне прояснили ситуацию о том как максимально быстро _ПРИСТУПИТЬ_ к созданию — не создать

Это разные вещи.

MF>(может я ее некорретно выразил — но она такова, определитmcя с платформой на которой создавать систему автоматизации, при наличии штата программистов в 3-человека, у которых объем знаний — 1С не более.

Э-э-э...

MF>При том что начальство желает занять нишу поставщиков корпоративных АСУ в городе.)

Да-а-а-а....

MF>Или может ты хочешь сказать что изучить JAVU С# и другие языке получиться быстрее чем изучить VC.

Конечно быстрее.

MF>А единственное тове мнение что я буду сидеь за дебаггером и ловить мемори-лики то что-то мнея берето соменение что Джава такая уж безгрешная.

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

MF>Есть одна поговорка "Шож если они такие умные — то помему они строем не ходят?". Что то я не заметил что бы AXAPTA например была написана на джаве или та же 1С например?

Ну, Axapta писалась не "штатом программистов в 3-человека, у которых объем знаний — 1С не более".
И я не сильно удивлюсь, если она будет переписана для .NET.

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

MF>Уважаемый BME я "не первый год замужем"

Это разные вещи.

извиняюсь еще раз. опыт накопленный человечеством (не очень высокопарно?) настойчиво подсказывает, что все-таки задачи учета хоз. деятельности предприятий ПРОЩЕ решать соответствующими инструментами. пример — приобретения Navision (те же по сути конструкторы хоздеятельности пишут) MS-ом лишнее тому подтверждение.
не надо лопатой копать огромные каналы. для этого экскаваторы существуют.
да, экскаватором не вскопаешь огород. картошку не соберешь. а лопатой можно и картошку и канал. все правильно.
но кесарево и слесарево надо различать.

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

Здравствуйте, <Аноним>, Вы писали:

А>с этим не могу не согласиться. вещь действительно нужная.
А>правда, есть маленький контраргумент — конфы пишутся маленькими коллективами (1-5 человек). даже очень серьезные: об ИТРП слышали. так вот 5 человек трудится. типовые 1с-е конфы вообще пишут по 1-м — 2-мя разработчиками.

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

... << RSDN@Home 1.0 beta 6a (developer build)>>

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

MF>1. Внедренцев 1С -у нас в городе выше крыши. И исправление их ошибок меня уже достатет

А ты подумал о том что даже при успешном создании платформы кто то должен писать под них конфигурации? А это означает что кто то должен править их на каждый писк наших законодателей, т.е. на практике целый коллектив должен заниматься правкой базовых конфигураций и ни чем более. В случае 1С сама фирма бесплатно распространяет обновления.

MF>2. На VC (или скажем так С++) можно написать как низкоуровневую задачу, так и задачу бизнеслогики,

Зачем тебе низкоуровневые задачи в ERP? А в качество средства описания бизнес-правил С++ очень плохо подходит. Посмотри на рынок — чего только не используют для этого — VBA, собственные языки, SQL и прочая. Вот только С++ еще никто в коробочных системахх не догадался для этого применить.

MF> Т.е. язык достаточно гибкий (хотя и сложный в освоении, но как говорил всем известный человек: "тяжело в учении — легко в бою")

Java и C# языки не менее гибкие, а в чем то даже более. С добавлением шаблонов оба будут практически полностью реализовывать навороты С++.

MF>3. Я в данный момент услиенно изучаю ООАП (объектно ориентированное проектирование)

Т.е. ты даже ООП еще изучаешь, а с понятием патерны наверное пока не знаком? Чего ж ты тогда споришь так усердно с теми кто на этом собаку съел?

Но Джаву нехочу — она как и C# сильно привязана к платформе на которой летает

То есть как это? Ничего менее привязанного к конкретной платформе из универсальных средств разработки нежели джава пока не существует.

MF> Хотя это только мое мнение — но все равно нехочу (и давайте не будем спорить хороша она ли и плоха)

Не знаю и спорить нехочу. Очень странная позиция.

MF>Ну и просто, особое мнение — чем тажелее труд тем больше внимательности — ато так, не заботимся о памяти? — во как класно сюда 100К туда 100К в результате скорость в дауне памяти нехватает

Со скоростью там все в порядке, насчет памяти — посмотри в прайс листы.

... << RSDN@Home 1.0 beta 6a (developer build)>>

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

AVK>Здравствуйте, <Аноним>, Вы писали:

А>>с этим не могу не согласиться. вещь действительно нужная.
А>>правда, есть маленький контраргумент — конфы пишутся маленькими коллективами (1-5 человек). даже очень серьезные: об ИТРП слышали. так вот 5 человек трудится. типовые 1с-е конфы вообще пишут по 1-м — 2-мя разработчиками.

AVK>Никогда не сталкивался с ситуациями, когда приходится править базовую конфигурацию, а потом каждую новую версию ручками склеивать с той что у тебя? Системы управления версиями нужны прежде всего не тем кто базовые конфы создает, а тем кто ими пользуется.

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

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

DMV>
MF>>Есть одна поговорка "Шож если они такие умные — то помему они строем не ходят?". Что то я не заметил что бы AXAPTA например была написана на джаве или та же 1С например?

DMV>Ну, Axapta писалась не "штатом программистов в 3-человека, у которых объем знаний — 1С не более".
DMV>И я не сильно удивлюсь, если она будет переписана для .NET.

Вообщето я просил советов а не мычаний. Конструктивные предложения будут? Может посоветует что? А бекать и экать, я тоже умею

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

MF>Вообщето я просил советов а не мычаний. Конструктивные предложения будут? Может посоветует что? А бекать и экать, я тоже умею

Тебе посоветовали:
1) Бросить эту затею, ибо силами 3-х человек она просто неподъемна
2) Если все таки очень хочется то писать на .NET или Java.

... << RSDN@Home 1.0 beta 6a (developer build)>>

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

Не будет легко и в бою тоже. Слишком много мелких деталей придется держать в голове, включая пресловутое управление памятью. А уж о сопровождении вообще промолчу.

MF>Но Джаву нехочу — она как и C# сильно привязана к платформе на которой летает

Бред.

Здравствуйте, Аноним, Вы писали:

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

А>
MF>>Уважаемый BME я "не первый год замужем"

Это разные вещи.

А>извиняюсь еще раз. опыт накопленный человечеством (не очень высокопарно?) настойчиво подсказывает, что все-таки задачи учета хоз. деятельности предприятий ПРОЩЕ решать соответствующими инструментами. пример — приобретения Navision (те же по сути конструкторы хоздеятельности пишут) MS-ом лишнее тому подтверждение.
А>не надо лопатой копать огромные каналы. для этого экскаваторы существуют.
А>да, экскаватором не вскопаешь огород. картошку не соберешь. а лопатой можно и картошку и канал. все правильно.
А>но кесарево и слесарево надо различать.

А>если же Вас интерисует корневой вопрос с точки зрения оценки целесообразности подобного начинания, тогда понимаю, и даже в чем-то разделяю.

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

, а потом еще и умудрится впарить этот продукт, предприятию, которой на 1С смотрит как на дорогостоящий продкут? Я не знаю, наверное надо быть Билли Гейтсом что бы себе такое позволить?.

То что я собираюсь писать трехзвенку совершенно не означает что она сразу же займет нишу разряда AXAPTA или например SAP R3, основная задача — это создать свой продукт, который можно поддерживать и отвечать, за него самостоятельно. Аксапту ведь тоже не господь бог написал

А>но на с++ почти с нуля бизнес автоматизировать, это все равно что отказаться от экскаваторов и повсеместно перейти на лопаты. имхо, конечно

Ага, только еще сначала лопату сделать

AVK>Тебе посоветовали:
AVK>1) Бросить эту затею, ибо силами 3-х человек она просто неподъемна
AVK>2) Если все таки очень хочется то писать на .NET или Java.

Да

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

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

MF>>Вообщето я просил советов а не мычаний. Конструктивные предложения будут? Может посоветует что? А бекать и экать, я тоже умею

AVK>Тебе посоветовали:
AVK>1) Бросить эту затею, ибо силами 3-х человек она просто неподъемна
И пойти торговать газетами? Так?.

AVK>2) Если все таки очень хочется то писать на .NET или Java.
Значит перефразирую вопрос из первого топика "Подскажите где почитать что бы в максимально короткие сроки приступить к разработке трехзвенки но уже на .NET или Java"

Что от этого Ваши ответы станут лучше? А посоветовать бросить я и сам себе могу. Это то что постоянно сидит у меня в голове — брось эту работу и иди на базар кроссовками торговать — там больше денег можно заработать.

Да еще и такие как Вы у меня скуплятся будете

(Для тех кто непонимает — это шутка, прошу без обид)

MF>Но извините автоматизировать горнодобывающее предприятие с территориальным разделением в несколько 10-ков километров с количеством различных подразделений перевалившим за 50 на 1С — это помоему еще больший мазохизм чем изучать VC. (только не надо тыкать носом в примеры что 1С именно на таких предприятиях работает, видел, и знаю что это значит)

Ну чего вас на VC заклинило?
Scala вон вроде вообще на VB большей частью написана.
Сейчас скорее всего начнутся наезды на VB.
Поэтому сразу в защиту:
1. Позволяет быстро создавать COM-компоненты, правда с ограничениями (не все потоковые модели и т.д.), но как правило для такого класса задач достаточно.
2. Позволяет (и изначально предназначен) создавать UI.
3. Легок (по сравнению с VC) в освоении.

И, самое главное, проверен временем и уже устарел — как раз то, чего Вы хотели.

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

AVK>>Тебе посоветовали:
AVK>>1) Бросить эту затею, ибо силами 3-х человек она просто неподъемна
MF>И пойти торговать газетами? Так?.

Нет, заняться тем что тебе по силам и набираться опыта. Если только газетами торговать то наверное пойти торговать газетами.

MF>Значит перефразирую вопрос из первого топика "Подскажите где почитать что бы в максимально короткие сроки приступить к разработке трехзвенки но уже на .NET или Java"

Тут не читать, тут пробовать и думать надо. А читать — по нету Рихтера, www.microsoft.com/net, далее .NET Architecture Center. По джаве для начала Брюса Эккеля — Философия Java, потом книжку по J2EE, java.sun.com. Ну а далее появятся конкретные вопросы, на которые можно будет дать конкретные ответы.

MF>Что от этого Ваши ответы станут лучше? А посоветовать бросить я и сам себе могу. Это то что постоянно сидит у меня в голове — брось эту работу и иди на базар кроссовками торговать — там больше денег можно заработать.

Торговать я тебе не предлагал.

... << RSDN@Home 1.0 beta 6a (developer build)>>

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

надысь было ДР Боба Марлей.. Сие послание очень в тему... Думаю некоторые меня поймут (гыгыгыгы)

dad>надысь было ДР Боба Марлей.. Сие послание очень в тему... Думаю некоторые меня поймут (гыгыгыгы)

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

MF>Еще раз повторяю, я не начальник ИВЦ на автоматизируемом предприятии.А наооброт, человек которых желает создать систему на которой можно деньги зарабатывать. А Вы предлагаете, сначала, купить аксапту, потом пройти кучу дорогостоящих курсов по обучению работы и программирования на ней же

, а потом еще и умудрится впарить этот продукт, предприятию, которой на 1С смотрит как на дорогостоящий продкут? Я не знаю, наверное надо быть Билли Гейтсом что бы себе такое позволить?.

MF>То что я собираюсь писать трехзвенку совершенно не означает что она сразу же займет нишу разряда AXAPTA или например SAP R3, основная задача — это создать свой продукт, который можно поддерживать и отвечать, за него самостоятельно. Аксапту ведь тоже не господь бог написал

Люди освоились, и нечего у них там и свой язык и модули под них люди пишут (слои — так помоему они у них называются). Но это все после чего? После первого проекта на котором она и родилась. У меня есть такой проект. И я то же хочу создать систему которая (возможно) будет иметь некоторое развитие.

MF>Но извините автоматизировать горнодобывающее предприятие с территориальным разделением в несколько 10-ков километров с количеством различных подразделений перевалившим за 50 на 1С — это помоему еще больший мазохизм чем изучать VC. (только не надо тыкать носом в примеры что 1С именно на таких предприятиях работает, видел, и знаю что это значит)
MF>

все. понял.

бедные мы. много нас. задачи серьезные.

обычная ситуация.

все же советую дождаться 8-ки (пара месяцев осталась). прикидочно — по мощности (пограммной платформы) сродни платформам типа Scala, Axapta. по цене не знаю. думаю, что проблем с нелицензионкой + документацией в РФ не будет

опять же куча ГОТОВЫХ разработчиков. и НЕ ДОРОГИХ в свой общей массе.

это не та 1с, которая есть сейчас (v77). повторяю, платформа значительно более зрелая.

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

dad>>надысь было ДР Боба Марлей.. Сие послание очень в тему... Думаю некоторые меня поймут (гыгыгыгы)
DMV>

да уж

Вообщем почитал я тут Ваши ответы господа и создалось у меня впечатление что сидят на этом форуме люди которые только и пушут что на AXAPTE (1С, SAP R3, ПАРУС и т.д.) и своего ничего не создают

. Под своим я имею ввиду системы автоматизации. А не игры типа Lines и им подобным.

Вот только мучате меня одни вопрос (да и не только один, но задам я один) зачем это все Микрософту, создавать такую мощную вещь как VC, что бы все отговаривали не ней не писать? Неужели она нужна только для того что бы драйвера писать да утилитки мелкие?
Непонимаю. Вообщем это все ....

MF>Вот только мучате меня одни вопрос (да и не только один, но задам я один) зачем это все Микрософту, создавать такую мощную вещь как VC, что бы все отговаривали не ней не писать? Неужели она нужна только для того что бы драйвера писать да утилитки мелкие?

Ну вот, уже колебаться начал, добрый знак.
VC действительно создан (в первую очередь) для достаточно низкоуровневого программирования. Но не для описания бизнес-логики!
Посмотри на любую финхоз систему — ядро (конструктор, среда, у кого как) написано с использованием низкоуровненых средств (и то не всегда). А вся бизнес-логика — на каком-то высокоуровневом языке. Непонятно, кстати, всеобщее желание непременно создать свой язык, но это тема для отдельного разговора (вроде уже где-то здесь обсуждалось).

MF>Непонимаю. Вообщем это все ....

Но ход мыслей правильный

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

MF>Вообщем почитал я тут Ваши ответы господа и создалось у меня впечатление что сидят на этом форуме люди которые только и пушут что на AXAPTE (1С, SAP R3, ПАРУС и т.д.) и своего ничего не создают

. Под своим я имею ввиду системы автоматизации. А не игры типа Lines и им подобным.

MF>Вот только мучате меня одни вопрос (да и не только один, но задам я один) зачем это все Микрософту, создавать такую мощную вещь как VC, что бы все отговаривали не ней не писать? Неужели она нужна только для того что бы драйвера писать да утилитки мелкие?
MF>Непонимаю. Вообщем это все ....

ну вот такое сравнение:
есть тяжелое машиностроение.
есть огромные агрегаты — доменные печи, прокатные станы...

так вот чтобы вскопать огород можно:
либо
1. — найти месторождение руды.
— построить кирпичный завод.
— из продукции кирпичного завода сложить доменную печь.
..... (долго писать)
— из полученных комплектующих собрать экскаватор.
— вскопать огород.
либо
2. — купить экскаватор
— вскопать огород.

кесарю-кесарево...

В догонку:

MF>>Вот только мучате меня одни вопрос (да и не только один, но задам я один) зачем это все Микрософту,
Да незачем это ему, оттого и купил Navision.

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

MF>Вот только мучате меня одни вопрос (да и не только один, но задам я один) зачем это все Микрософту, создавать такую мощную вещь как VC, что бы все отговаривали не ней не писать? Неужели она нужна только для того что бы драйвера писать да утилитки мелкие?

К твоему сведению, VC уже лет 5 как не менялась, поэтому сложно говорить, о том, что Microsoft на данным момент позиционирует VC, как средство для решения задач твоего уровня сложности.

Если бы ты тот же самый вопрос задал 5 лет назад, то ответ был бы, брать VC.

Но на данный момент VC уже устарел и задачи твоего плана (создать свое средство автоматизации предприятий) лучше решать на .Net-е.

зы
То, что ты выбрал VC, вместо .Net-а (причем безоговорочно), и вызвало бурный флейм остальных.
Если бы ты сразу бы выбрал бы .Net, то и разговор бы пошел в более конструктивном русле.

... << RSDN@Home 1.0 beta 6 >>

DG>Если бы ты сразу бы выбрал бы .Net, то и разговор бы пошел в более конструктивном русле.
Ага, все сказали бы "плюнь на это, если у тебя только 2 человека, которые кроме 1С ничего не знают".
Вообще все это юношеским максимализмом попахивает.

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

MF>>Вот только мучате меня одни вопрос (да и не только один, но задам я один) зачем это все Микрософту, создавать такую мощную вещь как VC, что бы все отговаривали не ней не писать? Неужели она нужна только для того что бы драйвера писать да утилитки мелкие?

DMV>Ну вот, уже колебаться начал, добрый знак.
DMV>VC действительно создан (в первую очередь) для достаточно низкоуровневого программирования. Но не для описания бизнес-логики!
DMV>Посмотри на любую финхоз систему — ядро (конструктор, среда, у кого как) написано с использованием низкоуровненых средств (и то не всегда). А вся бизнес-логика — на каком-то высокоуровневом языке. Непонятно, кстати, всеобщее желание непременно создать свой язык, но это тема для отдельного разговора (вроде уже где-то здесь обсуждалось).

Господа если Вы не поняли изначально — то я именно о ядре в первую очередь и говорил. Именно ядро меня и интересует

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

MF>>Непонимаю. Вообщем это все ....

DMV>Но ход мыслей правильный

Я не собираюсь отказываться от VC, отазываться еще пока неотчего

Я только собираюсь на нем разрабатывать, просто нехочется делать все на Delphi, ну а на 1С и тем более.

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

DG>>Если бы ты сразу бы выбрал бы .Net, то и разговор бы пошел в более конструктивном русле.
DMV>Ага, все сказали бы "плюнь на это, если у тебя только 2 человека, которые кроме 1С ничего не знают".
DMV>Вообще все это юношеским максимализмом попахивает.

Мало ли чем это попахивает — что делать? Пусть будет .Net какая разница. на VC тоже можно писать под .net
Предлагайте конкретные шаги которыме мне нужно сделать что бы начать (пусть даже и имея двух специалистов по 1С)

Кстати 1С я не совсем бросать соибираюсь, надеюсь она будет кормить нашу фирму еще долгое время. Но задуматься об альтернативе надобно. Иначе.... зачем тогда такие форумы?

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

DG>Если бы ты сразу бы выбрал бы .Net, то и разговор бы пошел в более конструктивном русле.

Ну или хотя бы вынес вопрос на обсуждение. А то что такое .NET я не знаю, что такое Java не знаю, что такое vC не знаю, даже что такое ООП не полностью представляю, но писать буду исключительно на VC. Одно из двух — либо у него логика совсем не к черту, либо все таки какие то причины есть, но он ими делиться не хочет.

... << RSDN@Home 1.0 beta 6a (developer build)>>

MF>Кстати 1С я не совсем бросать соибираюсь, надеюсь она будет кормить нашу фирму еще долгое время. Но задуматься об альтернативе надобно. Иначе.... зачем тогда такие форумы?

А что, консультирование по 1С — тоже хороший бизнес. При правильной постановке. Но внедренцев 1С — как собак нерезанных.
Теперь Axapta в моду входит. Так может лучше эту нишу занять? Сделать добротную конфигурацию и продавать.Народ об Axapta вроде неплохо отзывается.
Это я к тому, что если хотите самостоятельно выходить на рынок, то разработка своего продукта — не лучшее решение.
Вы даже представить себе не можете, каких трудов и финансовых вливаний это потребует.

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

MF>Господа если Вы не поняли изначально — то я именно о ядре в первую очередь и говорил. Именно ядро меня и интересует

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

MF>Я не собираюсь отказываться от VC, отазываться еще пока неотчего

Я только собираюсь на нем разрабатывать, просто нехочется делать все на Delphi, ну а на 1С и тем более.

уважаю отважных людей. серьезно. без сарказма.
если так, тогда что уж вам какой-то комбинатик автоматизировать. если будет написано хорошее ядро, соответствующий макетинг, глядишь с 1С, сапом, аксаптой.. сможете конкурировать. иначе, имхо, овчинка выделки не стоит. тратить лет 5 жизни ради написания движка, который будет востребован 2-3 клиентами, опять же имхо, не серьезно.
украсть — так миллион...

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

DMV>Теперь Axapta в моду входит. Так может лучше эту нишу занять? Сделать добротную конфигурацию и продавать.Народ об Axapta вроде неплохо отзывается.

Ты думаешь там нет "добротной конфигурации"? А для специфики — отраслевые решения.

... << RSDN@Home 1.0 beta 3 >>

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

MF>Мало ли чем это попахивает — что делать? Пусть будет .Net какая разница.

Очень большая

MF>на VC тоже можно писать под .net

Можно, но не нужно. Тем более что не на VC, а на МС++.

MF>Предлагайте конкретные шаги которыме мне нужно сделать что бы начать (пусть даже и имея двух специалистов по 1С)

Купить книжку Гамма и Ко "Паттерны ОО программирования" и внимательнейшим образом ее прочитать. Далее все таки определиться — .NET или Java. Если нет необходимости работы на мейнфреймах под юнихами то наверное .net предпочтительнее. Далее выбрать предварительную схему твоей системы.
0) Определиться — какая тебе нужна от сервера функциональность. Т.е. от простейших триггеров и ХП вроде MIDAS до полномасштабного фреймворка вроде решений J2EE.
1) клиент толстый, тонкий, сверхтонкий, веб браузер.
2) Хранилище — РСУБД или ООСУБД.
3) Представление данных внутри сервера — курсоры, xml, объектное.
4) Выбрать механизм меппинга (зависит от п.3).
5) Местоположение, формат хранения и язык бизнес-приложений
6) Схема идентификации и аутентификации
7) Схема балансировки
8) Жизненный цикл объектов в БД. Их возможные типы — стейтлес, стейтфул, энтити.
9) Механизм контроля версий.
10) Алгоритмы кеширования.
11) Конфигурирование.
12) Механизмы взаимодействия между клиентом и сервером. В случае .NET это прежде всего Remoting и веб сервисы. Для джавы это RMI.

Это самые самые базовые вопросы, которые должны быть решены прежде чем ты напишешь хоть строчку кода.

PS: У нас тут на rsdn.ru народ собирается, да все никак не соберется писать свой сервер приложений под дотнет. Так может тебе лучше их потерзать и самому принять деятельное участие в этом проекте?

PPS: На Java есть много готовых серверов приложений — как очень мощных коммерческих, так и бесплатных. Так может тебе не писать свою среду исполнения а воспользоваться готовым сервером? Для начала можешь посмотреть Resin-EJB (www.caucho.com) и Orion Application Server (http://www.orionserver.com/). Оба довольно простые, имеют приемлемую документацию и бесплатны для некоммерческой разработки. Когда понадобится тяжелое решение то есть BEA Web Logic, Borland Application Server.
Для дотнета готового сервера приложений нет, есть возможность интеграции классов .NET в среду СОМ+. То есть тот самый DCOM о котором ты в первом посте поминал.

... << RSDN@Home 1.0 beta 6a (developer build)>>

K>Ты думаешь там нет "добротной конфигурации"? А для специфики — отраслевые решения.
Я думаю что есть, просто хотел сказать, что выгоднее и проще найти свою нишу на уже сформировавшемся рынке, чем пытаться осчастливить мир. Дешевле обойдется.

Здравствуйте, Аноним, Вы писали:

А>уважаю отважных людей. серьезно. без сарказма.
А>если так, тогда что уж вам какой-то комбинатик автоматизировать. если будет написано хорошее ядро, соответствующий макетинг, глядишь с 1С, сапом, аксаптой.. сможете конкурировать. иначе, имхо, овчинка выделки не стоит. тратить лет 5 жизни ради написания движка, который будет востребован 2-3 клиентами, опять же имхо, не серьезно.
А>украсть — так миллион...

Вот когда напишу ядро, тогда и буду губы пялить

Да маркетинг искать, а так пока только мысли

Да попытки найти соответствующую помощь, в этом деле.

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

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

DG>>Если бы ты сразу бы выбрал бы .Net, то и разговор бы пошел в более конструктивном русле.

AVK>Ну или хотя бы вынес вопрос на обсуждение. А то что такое .NET я не знаю, что такое Java не знаю, что такое vC не знаю, даже что такое ООП не полностью представляю, но писать буду исключительно на VC. Одно из двух — либо у него логика совсем не к черту, либо все таки какие то причины есть, но он ими делиться не хочет.

AVK>
Причина одна — недостаток времени на обучение. Т.е. предполагается что будем обучаться находу по мере возможности, так сказать на рабочем проекте. А вот про ООП зря Вы так, достаточно долго его изучаю, правда это если об ООП как об объектно ориентированном программировании, если дело идет о проектировании то тут Вы правы

изучать мне его еще и ищучать

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

MF>Причина одна — недостаток времени на обучение.

Поэтому выбираем самый сложный для изучения язык? По прежнему не вижу логики.

MF>если дело идет о проектировании то тут Вы правы

изучать мне его еще и ищучать

.

Потому и посоветовал тебе книжку про паттерны.

... << RSDN@Home 1.0 beta 6a (developer build)>>

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

AVK>Можно, но не нужно. Тем более что не на VC, а на МС++.

AVK>Купить книжку Гамма и Ко "Паттерны ОО программирования" и внимательнейшим образом ее прочитать. Далее все таки определиться — .NET или Java. Если нет необходимости работы на мейнфреймах под юнихами то наверное .net предпочтительнее. Далее выбрать предварительную схему твоей системы.

Книжку эту я купить не могу. Говорят ее выпускать перестали, а в электронном виде нету (на русском)

Ладно, будем считать Вы меня уломали

Я определился, буду писать под нет

AVK>0) Определиться — какая тебе нужна от сервера функциональность. Т.е. от простейших триггеров и ХП вроде MIDAS до полномасштабного фреймворка вроде решений J2EE.
Ой господи даже и не знаю

Вообщем то мне нужен AppServer на котором будет крутится контроль прав и бизнес логика, может это и Хранимые процедуры и триггеры, но мне кажется что это чуть чуть боьлше. К сожалению я не изучал концепций J2EE поэтому не могу сказать нужен ли мне его фреймворк

. Если вкратце опишете перспективы его, и это меня заинтересует. То изучу детальнее.

AVK>1) клиент толстый, тонкий, сверхтонкий, веб браузер.
Предполагается средней тонкости. Т.е. банальные запросы на выполнение операции и вывод данных на экран, вся логика — дело сервера.
AVK>2) Хранилище — РСУБД или ООСУБД.
РСУБД
AVK>3) Представление данных внутри сервера — курсоры, xml, объектное.
Какого сервера? Разрабатываемого мной? — все должно быть в виде объектов.

AVK>4) Выбрать механизм меппинга (зависит от п.3).
Что такое меппинг? Не встречал этого понятия в совей практике? Объясните в двух словах не более общий смысл.

AVK>5) Местоположение, формат хранения и язык бизнес-приложений
Бизнес-логике — на сервере приложений (средний уровень), формат хранения??? (непонимаю) если имеется ввиду каким образом будут они подключаться к серверу, то планирую расширяемые модули, плагины (скорее всего ДЛЛ).
AVK>6) Схема идентификации и аутентификации
В этом месте много открытых вопросов. Я их планировал задавать когда приступлю к реализации. Приблизительно так: данные о пользователях на сервере, у каждого есть права на выполнение операций бизнес-логики а также права на доступ к конкретным объектам бизнес логики и соответсвенно суммирование прав на выполнение операции с правами на доступ к конкретному объекту.

AVK>7) Схема балансировки
Не значю что это

Надеюсь пока незнаю.

AVK>8) Жизненный цикл объектов в БД. Их возможные типы — стейтлес, стейтфул, энтити. (пока тоже слабо понимаю очем говорят эти три термина) Но думаю у разных объектов будут разные жизненные циклы, как можно говорить об этом заранее?

AVK>9) Механизм контроля версий.
Собираюсь просить помощи в этом вопросе у общественности.

AVK>10) Алгоритмы кеширования.
необдумывал

AVK>11) Конфигурирование.
Конфигурирование планировалось — параметрическое. т.е. первые версии продукта будут таки сильно стеснены в вопросах конфигурирования. Т.е. под каждую автоматизируемую задачу планировалось написание дополнительных модулей(как для серверов так и для клиентов)

AVK>12) Механизмы взаимодействия между клиентом и сервером. В случае .NET это прежде всего Remoting и веб сервисы. Для джавы это RMI.
Вопрос остается открытым, с моей колоколни — самый главный вопрос- выяснить как передавать наборы записей (например табличную часть накладной) от сервера клиенту???

AVK>Это самые самые базовые вопросы, которые должны быть решены прежде чем ты напишешь хоть строчку кода.
Я надеюсь Вы мне поможете пролить свет на эти вопросы, внести ясность так сказать. Ибо многие из этих вопросов тяжело разрешить самостоятельно в сжатые сроки (ибо как распылены они по литературе достоточно широко)

AVK>PS: У нас тут на rsdn.ru народ собирается, да все никак не соберется писать свой сервер приложений под дотнет. Так может тебе лучше их потерзать и самому принять деятельное участие в этом проекте?
Можно ссылку почитать посмотреть?

AVK>PPS: На Java есть много готовых серверов приложений — как очень мощных коммерческих, так и бесплатных. Так может тебе не писать свою среду исполнения а воспользоваться готовым сервером? Для начала можешь посмотреть Resin-EJB (www.caucho.com) и Orion Application Server (http://www.orionserver.com/). Оба довольно простые, имеют приемлемую документацию и бесплатны для некоммерческой разработки. Когда понадобится тяжелое решение то есть BEA Web Logic, Borland Application Server.

AVK>Для дотнета готового сервера приложений нет, есть возможность интеграции классов .NET в среду СОМ+. То есть тот самый DCOM о котором ты в первом посте поминал.
Скорее всего буду именно это и использовать. Посему хотелось бы примеров (может банальных, но откражающих суть этого вопроса) Может даже и на MC++

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

DMV>Ага, только еще сначала лопату сделать

Зато можно ТАКУЮ лопату забабахать! С гидроусилителем, автоотбрасывателем земли, ортопедической ручкой и управляемую мозговыми импульсами!

RSDN@Home

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

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

MF>>Причина одна — недостаток времени на обучение.

AVK>Поэтому выбираем самый сложный для изучения язык? По прежнему не вижу логики.

MF>>если дело идет о проектировании то тут Вы правы

изучать мне его еще и ищучать

.

AVK>Потому и посоветовал тебе книжку про паттерны.

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

Здравствуйте, Аноним, Вы писали:

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

dad>>>надысь было ДР Боба Марлей.. Сие послание очень в тему... Думаю некоторые меня поймут (гыгыгыгы)
DMV>>

А>да уж

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

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

Хоть один вразумительный довод. Но, имхо, ваше мнение ошибочно, как раз все наоборот.

... << RSDN@Home 1.0 beta 3 >>

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

AVK>PPS: На Java есть много готовых серверов приложений — как очень мощных коммерческих, так и бесплатных. Так может тебе не писать свою среду исполнения а воспользоваться готовым сервером? Для начала можешь посмотреть Resin-EJB (www.caucho.com) и Orion Application Server (http://www.orionserver.com/). Оба довольно простые, имеют приемлемую документацию и бесплатны для некоммерческой разработки. Когда понадобится тяжелое решение то есть BEA Web Logic, Borland Application Server.
Я бы еще http://www.jboss.org/ упомянул.

... << RSDN@Home 1.0 beta 6 >>

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

S>Я бы еще http://www.jboss.org/ упомянул.

Глючен он, как хороший косяк.

... << RSDN@Home 1.0 beta 6a (developer build)>>

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

AVK>Глючен он, как хороший косяк.
Некжто до сих пор? Мы с ними имели дело ажно в 2000м. Хорошая была заявка на успех. И цена подходяшшая.

... << RSDN@Home 1.0 beta 6 >>

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

MF>Ой господи даже и не знаю

. Если вкратце опишете перспективы его, и это меня заинтересует. То изучу детальнее.

Центральное звено J2EE это EJB-сервер — среда исполнения для enterprise java beans, т.е. бизнес-компонент. Бины бывают 2 видов: сессионные(session beans) и сущности(entity beans). Сессионные бины в свою очередь подразделяются на стейтлесс(не хранящие состояние, по сути просто набор процедур) и стейтфул(хранящие состояние). Стейтлесс бины самые быстрые, по сути они общие на всех клиентов, но в каждый конкретный момент этим бином пользуется только один клиент, т.е. многопоточного исполнения нет. Для параллельного исполнения кода создается пул таких бинов. Стейтфул бины создаются для каждого клиента свои и живут в течение его сессии.
Энтити бины это компоненты, отражающие персистентные объекты, срок жизни которых превышает срок жизни самого процесса сервера. Обычно их состояние хранится в РСУБД. Они в свою очередь тоже бывают двух видов — BMP (bean managed persistence) и CMP(container managed persistence). Первые должны содержать два специальных метода — Load и Save, в которых ты сам должен загрузить или сохранить объект где тебе необходимо. Во вторых код этих методов генерируется автоматически. Т.е. фактически ты просто описываешь набор свойств компонента, а хранение в БД целиком ложится на контейнер.
Кроме того в EJB-сервере как правило есть куча дополнительных сервисов. Прежде всего сервис взаимодействия с клиентом. Далее обязательно сервер имен. Очень часто веб-сервер с servlets&JSP engine. Очень часто бывает менеджер соединений с БД. Аутентификация как правило накручивается сверху на основе JAAS, хотя в jboss по моему она уже встроена.

AVK>>1) клиент толстый, тонкий, сверхтонкий, веб браузер.
MF>Предполагается средней тонкости. Т.е. банальные запросы на выполнение операции и вывод данных на экран, вся логика — дело сервера.

Это уже тонкий клиент.

AVK>>4) Выбрать механизм меппинга (зависит от п.3).
MF>Что такое меппинг? Не встречал этого понятия в совей практике? Объясните в двух словах не более общий смысл.

У как все запущено. В РСУБД данные храняться ввиде плоских таблиц, связанных отношениями в иерархическую структуру. Объекты в программе представляют собой структуру сетевую. Преобразование модели данных хранилища в модель данных сервера называется mapping. Судя по твоему выбору тебе нужен OO<->Relational mapping. Создание такого меппинга так чтобы он был не более чем на порядок медленнее обычного обращения на групповых операциях нетривиальная задача в общем то.

MF>Бизнес-логике — на сервере приложений (средний уровень), формат хранения??? (непонимаю) если имеется ввиду каким образом будут они подключаться к серверу, то планирую расширяемые модули, плагины (скорее всего ДЛЛ).

Ага, тут ты похоже даже не думал. Подумай о том что есть технологии динамической компиляции, т.е. приложение можно распространять прямо в исходных текстах, есть xml. Стоит задуматься и о механизме деплоймента. В случае СОМ+ деплоймент превращается в адову работу.

AVK>>6) Схема идентификации и аутентификации
MF>В этом месте много открытых вопросов. Я их планировал задавать когда приступлю к реализации.

Низзя. Это очень часто встречающаяся ошибка. Пока ты не продумаешь базовые вопросы нельзя писать ни одной строчки кода, иначе потом придется все переписывать.

MF> Приблизительно так: данные о пользователях на сервере, у каждого есть права на выполнение операций бизнес-логики а также права на доступ к конкретным объектам бизнес логики и соответсвенно суммирование прав на выполнение операции с правами на доступ к конкретному объекту.

Как эти права задавать? Где хранить? Как обеспечивать безопасность обмена между сервером и клиентом? Какая политика назначения прав — по уровню, по группе, по индивидуальному пользователю или смешанная. Каким образом организованы объекты доступа — линейно, иерархически, сетевая структура или какая то их смесь?

AVK>>7) Схема балансировки
MF>Не значю что это

Надеюсь пока незнаю.

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

MF>(пока тоже слабо понимаю очем говорят эти три термина) Но думаю у разных объектов будут разные жизненные циклы, как можно говорить об этом заранее?

Посмотри описание EJB — идея то она везде общая. А планировать жизненные циклы нужно обязательно, это одна из основных характеристик сервера приложений.

AVK>>9) Механизм контроля версий.
MF>Собираюсь просить помощи в этом вопросе у общественности.

То есть тоже не думал. Плохо.

AVK>>10) Алгоритмы кеширования.
MF>необдумывал

Без этого производительность твоего сервера будет плачевной. А если еще и OO-Relational меппинг наличествует, то производительность без кеша объектов будет просто никакая.

AVK>>11) Конфигурирование.
MF>Конфигурирование планировалось — параметрическое. т.е. первые версии продукта будут таки сильно стеснены в вопросах конфигурирования. Т.е. под каждую автоматизируемую задачу планировалось написание дополнительных модулей(как для серверов так и для клиентов)

И тем не менее на дотнете можно реализовать полностью автоматическую систему конфигурирования произвольных модулей. Прообраз такой системы можно поглядеть в янусе ака RSDN@Home.
В джаве на конфигурирование есть стандарт — JMX.

AVK>>12) Механизмы взаимодействия между клиентом и сервером. В случае .NET это прежде всего Remoting и веб сервисы. Для джавы это RMI.
MF>Вопрос остается открытым, с моей колоколни — самый главный вопрос- выяснить как передавать наборы записей (например табличную часть накладной) от сервера клиенту???

Ну я же сказал — ремоутинг или веб-сервисы. Первый много гибче, второй позволит писать клиентов на С++, Дельфи, старом VB, но возможности у него куда как более скудные.

Да, совсем забыл — надо еще продумать механизм транзакций, в том числе и распределенных.

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

В сжатые сроки это сколько конкретно?

AVK>>PS: У нас тут на rsdn.ru народ собирается, да все никак не соберется писать свой сервер приложений под дотнет. Так может тебе лучше их потерзать и самому принять деятельное участие в этом проекте?
MF>Можно ссылку почитать посмотреть?

А нету пока даже ссылки. Так, треп пока один в форумах. Все ждут когда кто нибудь скажет — делаем. Но как минимум трое уже согласны

(Пользуясь случаем, передаю привет Владу, Синклеру и IT

)

AVK>>Для дотнета готового сервера приложений нет, есть возможность интеграции классов .NET в среду СОМ+. То есть тот самый DCOM о котором ты в первом посте поминал.
MF>Скорее всего буду именно это и использовать. Посему хотелось бы примеров (может банальных, но откражающих суть этого вопроса) Может даже и на MC++

Смотри в форуме по дотнету. Но там есть подводные камни. Прежде всего очень кривой деплоймент и кое какие неясности с событиями и колбеками.

... << RSDN@Home 1.0 beta 6a (developer build)>>

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

AVK>>Глючен он, как хороший косяк.
S>Некжто до сих пор?

Когда я его последний раз видел, а это было месяцев 10 назад, был еще весма глюкав. Текущее состояние не знаю.

S> Мы с ними имели дело ажно в 2000м. Хорошая была заявка на успех. И цена подходяшшая.

Ну цена то да

Но у нас, блин, Россия. Так что можно и резин с орионом ставить, никто следить не будет.

... << RSDN@Home 1.0 beta 6a (developer build)>>

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

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

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

K>Хоть один вразумительный довод. Но, имхо, ваше мнение ошибочно, как раз все наоборот.

У меня этих мнений как грязи. Какое из них ошибочно? И что наоборот?

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

AVK>Центральное звено J2EE это EJB-сервер — среда исполнения для enterprise java beans, т.е. бизнес-компонент. Бины бывают 2 видов: сессионные(session beans) и сущности(entity beans). Сессионные бины в свою очередь подразделяются на стейтлесс(не хранящие состояние, по сути просто набор процедур) и стейтфул(хранящие состояние). Стейтлесс бины самые быстрые, по сути они общие на всех клиентов, но в каждый конкретный момент этим бином пользуется только один клиент, т.е. многопоточного исполнения нет. Для параллельного исполнения кода создается пул таких бинов. Стейтфул бины создаются для каждого клиента свои и живут в течение его сессии.
AVK>Энтити бины это компоненты, отражающие персистентные объекты, срок жизни которых превышает срок жизни самого процесса сервера. Обычно их состояние хранится в РСУБД. Они в свою очередь тоже бывают двух видов — BMP (bean managed persistence) и CMP(container managed persistence). Первые должны содержать два специальных метода — Load и Save, в которых ты сам должен загрузить или сохранить объект где тебе необходимо. Во вторых код этих методов генерируется автоматически. Т.е. фактически ты просто описываешь набор свойств компонента, а хранение в БД целиком ложится на контейнер.
AVK>Кроме того в EJB-сервере как правило есть куча дополнительных сервисов. Прежде всего сервис взаимодействия с клиентом. Далее обязательно сервер имен. Очень часто веб-сервер с servlets&JSP engine. Очень часто бывает менеджер соединений с БД. Аутентификация как правило накручивается сверху на основе JAAS, хотя в jboss по моему она уже встроена.

Спасибо за разъяснение.

Но если Вы будете так добры что сможете указать мне литературу желательно в электронном виде, как это приложение сделать

Я с удовольствием возьмусь изучать джаву и закину все остальные потуги.

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

). Но пощупать не знаю как. Один из указанных Вами примеров я скачал, и даже распаковал

А что делать дальше как запустить пощупать — незнаю. И где брать джаву к сожалению тоже

AVK>>>1) клиент толстый, тонкий, сверхтонкий, веб браузер.
MF>>Предполагается средней тонкости. Т.е. банальные запросы на выполнение операции и вывод данных на экран, вся логика — дело сервера.

AVK>Это уже тонкий клиент.
Да я вообщем это и понимаю

.

AVK>>>4) Выбрать механизм меппинга (зависит от п.3).
MF>>Что такое меппинг? Не встречал этого понятия в совей практике? Объясните в двух словах не более общий смысл.

AVK>У как все запущено. В РСУБД данные храняться ввиде плоских таблиц, связанных отношениями в иерархическую структуру. Объекты в программе представляют собой структуру сетевую. Преобразование модели данных хранилища в модель данных сервера называется mapping. Судя по твоему выбору тебе нужен OO<->Relational mapping. Создание такого меппинга так чтобы он был не более чем на порядок медленнее обычного обращения на групповых операциях нетривиальная задача в общем то.

Ну не так уж все и запущено

Просто не попадались мне в руки книги которые Вы читали и не учился возможно я в нужных институтах, но это не уменьшает моего стремления изучить эту область, и знать!!!
То что придется объекты отражать на плоские таблицы я думал, и даже как то пытался продумать как это сделать. Если укажите книги где можно почитать об этом — то тоже великое Вам спасибо. Особенно об OO<->Relational маппинге

MF>>Бизнес-логике — на сервере приложений (средний уровень), формат хранения??? (непонимаю) если имеется ввиду каким образом будут они подключаться к серверу, то планирую расширяемые модули, плагины (скорее всего ДЛЛ).

AVK>Ага, тут ты похоже даже не думал. Подумай о том что есть технологии динамической компиляции, т.е. приложение можно распространять прямо в исходных текстах, есть xml. Стоит задуматься и о механизме деплоймента. В случае СОМ+ деплоймент превращается в адову работу.

Об адовой работе по деплойменту COM приложений я представление имею, как то пытался это провести на прошлоай работе. Тяжело получалось

.

А вот что такое динамическая компиляция и сколько ресурсов нужно будет положить на ее поддержку? представления не имею. Может все таки остановится на DLL (это всетаки мой первый проект, а как написано в книге "Мифический человеко-месяц") первый проект неполучается ниукого, но это не значит что его не нужно делать. Может все таки не насыпать все фишки в одну сборку. Возмжно какая либо поэтапная работа?

AVK>>>6) Схема идентификации и аутентификации
MF>>В этом месте много открытых вопросов. Я их планировал задавать когда приступлю к реализации.

AVK>Низзя. Это очень часто встречающаяся ошибка. Пока ты не продумаешь базовые вопросы нельзя писать ни одной строчки кода, иначе потом придется все переписывать.
Я имелл ввиду что сначала выспрошу у народа, выясню как а потом приступлю к кодированию, но процесс выспрашивания это уже будет фаза "приступлю к реализации". Щас например я еще определяюсь, и нахожусь в том состоянии что ваабще могу все закинуть и продолжать работать на 1С. Но если "приступлю к реализации" назад пути небудет.

MF>> Приблизительно так: данные о пользователях на сервере, у каждого есть права на выполнение операций бизнес-логики а также права на доступ к конкретным объектам бизнес логики и соответсвенно суммирование прав на выполнение операции с правами на доступ к конкретному объекту.

AVK>Как эти права задавать? Где хранить? Как обеспечивать безопасность обмена между сервером и клиентом? Какая политика назначения прав — по уровню, по группе, по индивидуальному пользователю или смешанная. Каким образом организованы объекты доступа — линейно, иерархически, сетевая структура или какая то их смесь?
Как задавать? Будет специальное приложение (чем то похожее на виндовый ЮзерМенеджер)
Где хранить? В базе конечно

Если есть более правильный вариант, с удовольствием выслушаю и приму к сведению.
Как обеспечить безопасность? Вот тот я плаваю

Жду от Вас многоуважаемая общественность конструктивной помощи. Как можно и как надо

Политика смешанная Группы+Пользователи+Уровень

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

AVK>>>7) Схема балансировки
MF>>Не значю что это

Надеюсь пока незнаю.

AVK>Схема распределения нагрузки на несколько серверов. Хорошие сервера приложений как правило умеют работать в составе кластера серверов, динамически распределяя между ними нагрузку, а иногда еще и бессбойная (ну или хотя бы со сбоем только у его клиентов) изоляция отказавшего сервера с непрерывностью функционирования кластера в целом.

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

MF>>(пока тоже слабо понимаю очем говорят эти три термина) Но думаю у разных объектов будут разные жизненные циклы, как можно говорить об этом заранее?

AVK>Посмотри описание EJB — идея то она везде общая. А планировать жизненные циклы нужно обязательно, это одна из основных характеристик сервера приложений.
Думаю, когда я напишу низкоуровневое ядро я вплотную займусь проектированиме объектов бизнеслогики, вот тогда и буду планировать жизденные циклы объектов.

Учитывая что Вы конкретно описали термины могу теперь точно сказать что большинство объектов будут меня типа Энтити, так как они будут хранится в БД, но будут и такие как стейтлес и стейтфул. Хотя это термины низкого уровня — безотносительно к безнес логике (как я это понимаю) ибо какого типа будет объект можно определить только на этапе проектировани бизнес-логики.

Т.е. сдесь выплывает своеобразное разделение севера среднего уровнян на две категори ядро сервера безотносительно к бизнес-логике и собственно сервер бизнеслогики.

AVK>>>9) Механизм контроля версий.
MF>>Собираюсь просить помощи в этом вопросе у общественности.

AVK>То есть тоже не думал. Плохо.
А какие варианты??? Их не так ужи и много. И кстати я думал

AVK>Без этого производительность твоего сервера будет плачевной. А если еще и OO-Relational меппинг наличествует, то производительность без кеша объектов будет просто никакая.
кеширование? — это ведь использование памяти? или например использование временных таблиц где хранятся уменьшенные выборки для работы с объектами? Все таким мне будет проще об этом думать когда я буду знать как работает мой сервер и что представляют из себя его объекты.

AVK>>>11) Конфигурирование.
MF>>Конфигурирование планировалось — параметрическое. т.е. первые версии продукта будут таки сильно стеснены в вопросах конфигурирования. Т.е. под каждую автоматизируемую задачу планировалось написание дополнительных модулей(как для серверов так и для клиентов)

AVK>И тем не менее на дотнете можно реализовать полностью автоматическую систему конфигурирования произвольных модулей. Прообраз такой системы можно поглядеть в янусе ака RSDN@Home.

Обязательно глянем. Но под конфигурированием лично я понимаю — возможность безграмотного в компьютерных понятиях бухгалтера изменить какое либо поведение системы (в переделах допущенных разработчиком). А не возможность крутообученного спеца ковыраясь в ини-файлах или в XML файлах изменить функционал системы в целом. Хотя и это я буду планировать.

По возможности так же параметрическим способом

Т.е. через какую либо твикующую программу или через диалог "Опции" например
AVK>В джаве на конфигурирование есть стандарт — JMX.

AVK>>>12) Механизмы взаимодействия между клиентом и сервером. В случае .NET это прежде всего Remoting и веб сервисы. Для джавы это RMI.
MF>>Вопрос остается открытым, с моей колоколни — самый главный вопрос- выяснить как передавать наборы записей (например табличную часть накладной) от сервера клиенту???

AVK>Ну я же сказал — ремоутинг или веб-сервисы. Первый много гибче, второй позволит писать клиентов на С++, Дельфи, старом VB, но возможности у него куда как более скудные.
Я не знаю что такое ремотинг или думаю что не знаю (может я о нем знаю совсем по другому названию) если ткнете в статью MSDN где можно о нем почитать. Буду знать лучше. Хотя и вариант вебсервисов скорее всего так же не оставлю без внимания

AVK>Да, совсем забыл — надо еще продумать механизм транзакций, в том числе и распределенных.
Буду стараться укладываться в тарнзакции SQL сервера (это что касается данных). Ну а там где это будет невозможно например транзакция безнес-логики

Буду что то выдумывать

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

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

AVK>В сжатые сроки это сколько конкретно?
Хочется начать уже завтра. Но это к сожалению невозможно

. Хочу весь этот мандраж по выяснению возможностей и определению языка реализации уместить в месяца 3-4. Ну а весь проект в 1-2 года.

AVK>>>Для дотнета готового сервера приложений нет, есть возможность интеграции классов .NET в среду СОМ+. То есть тот самый DCOM о котором ты в первом посте поминал.
MF>>Скорее всего буду именно это и использовать. Посему хотелось бы примеров (может банальных, но откражающих суть этого вопроса) Может даже и на MC++

AVK>Смотри в форуме по дотнету. Но там есть подводные камни. Прежде всего очень кривой деплоймент и кое какие неясности с событиями и колбеками.
Я так понимаю что Вы усиленно пытаетесь меня склонить к Джаве

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

А это у нас в крови

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

MF>Я уже давно прочитал и про COM и про нет. И мало того даже конкретно его применял. И то что поезд Микрософта уже давно мимо него проехал и забыл я тоже понимаю

Так в чём проблемы?

MF>Я так понимаю сидишь ты где нибудь в БАЛЬШУШЕЙ конторе в которой кто-то за тебя очень давно выбрал стратегию работы а тебе только говорят в какую сторону копать,

Не угадал, мне говорят какой нужен функционал, а я уже сам решаю где и куда копать.

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

Если ты внимательно читал мои постинги, где я немножко анализировал свой опыт (пользуясь случаем хочу передать привет ГВ), то ты должен был заметить, что с подобной проблемой я не просто сталкивался, но я её решал и довольно успешно. Эта самодельная комплексная САП, на которой работали (может и сейчас работает) больше десятка больших предприятий, кормила команду разработчиков и меня в том числе более 5 лет. Начинала она делалаться 10 лет назад, но существовала только в DOS версии и, к сожалению, Windows не пережила.

MF>(может я ее некорретно выразил — но она такова, определитmcя с платформой на которой создавать систему автоматизации, при наличии штата программистов в 3-человека, у которых объем знаний — 1С не более. При том что начальство желает занять нишу поставщиков корпоративных АСУ в городе.)

Мда, начальные условия не ахти.

MF>Что мне посоветушеь ответить руководству (котору кстати совершенно пофигу на чем я буду писать — хоть на ассемблере или даже на перфокартах) им важен результат. А я им скажу понимаете тут некий господин IT советует забить на все это потому что мы не потянем и все тут. Потому что мы пытаемся ехать на отсталых технологиях, а если начнем учить мнодные технологии — пройдет время и они поять станут отсталыми. Так что ли?

Разве я тебе советовал забить? Я пытаюсь тебя предостеречь от ошибок, которые ты начинаешь делать ещё не приступив к работе. Хочешь поговорить без понтов и конструктивном ключе? Давай, но только отложи в сторону "я уже решил" и "попрошу мне не указывать". Тогда может что-то и получиться. Я, например, исходя из моего опыта (псхпп ГВ) могу тебе расскать о тех граблять при проектировании и разработки на которые наступал я и моя команда. Кто-то может ещё что-то подскажет, но в таком ключе как ты начал никто тебе помогать не будет.

MF>Или может ты хочешь сказать что изучить JAVU С# и другие языке получиться быстрее чем изучить VC. А единственное тове мнение что я буду сидеь за дебаггером и ловить мемори-лики то что-то мнея берето соменение что Джава такая уж безгрешная.

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

MF>Есть одна поговорка "Шож если они такие умные — то помему они строем не ходят?". Что то я не заметил что бы AXAPTA например была написана на джаве или та же 1С например?

Не переживай, заметишь. Знаешь почему система, которую я делал померла? Потому что затраты на её перевод под Windows были бы не меньше чем вся разработка. Тоже самое касается и 1С. Возможно они хотят всё передалать, но они просто не могут себе это позволить, так как это очень дорого. Другое дело начинать с нуля. К тому же, если тебя действительно интересует распространённость тех или иных технологий, то сходи на любой job сайт и посмотри кто сейчас требуется. Думаю ты будешь сильно удивлён, что Java программистов требуется больше чем C++.

MF>И кстати клиенту у меня есть, и даже не одни. И я точно знаю что 1С — им не нужна

Это хорошо.

MF>А если ты на чужбине то пожалйста не путай подходы ихние с нашими

Они разные и очень на много.

Детский сад, штаны на лямках. Ей богу.

MF>Тот же заказчик например. Пришел ко мне и говорит мне нужна система. А я начитавшись разумных книшежек (О RUP и схожих с ними процессах) думаю, спросить у него чего нибудь или сразу сказать — будет сделано. Но по лицу видно что он нифига не знает как должна функционировать система. У нас до сих пор заказчики заказывает системы из престихных соображений а не для улучшения учета или еще чего то там

Говори им что хочешь, это твоё дело. Если ты хочешь здесь обсудить детали разработки АСУ предприяти, то это и надо делать. Если ты хочешь знать что нужно для того чтобы писать трёхзвенку на VC++, то тебе уже сказали: COM, ATL, ADO, MFC. Вперёд, только потом не говори, что тебя не предупреждали.

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

MF>Книжку эту я купить не могу. Говорят ее выпускать перестали, а в электронном виде нету (на русском)

Где-то нашел на англ. Где -- уже не помню, но могу своей поделиться

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

То, что доктор прописал!

RSDN@Home

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

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

W>
MF>>Книжку эту я купить не могу. Говорят ее выпускать перестали, а в электронном виде нету (на русском)

W>Где-то нашел на англ. Где -- уже не помню, но могу своей поделиться

.
W>Читается довольно легко. Авторы стараются избегать высокохудожественных оборотов.
W>Сухое лаконичное техническое описание.

То, что доктор прописал!

Давай

Мыло в профиле

Здравствуйте, Аноним, Вы писали:

А>все же советую дождаться 8-ки (пара месяцев осталась). прикидочно — по мощности (пограммной платформы) сродни платформам типа Scala, Axapta. по цене не знаю. думаю, что проблем с нелицензионкой + документацией в РФ не будет

Слушай, Аноним, а ты Сереге Кравченко передать привет можешь?

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

DMV>VC действительно создан (в первую очередь) для достаточно низкоуровневого программирования. Но не для описания бизнес-логики!
DMV>Посмотри на любую финхоз систему — ядро (конструктор, среда, у кого как) написано с использованием низкоуровненых средств (и то не всегда). А вся бизнес-логика — на каком-то высокоуровневом языке. Непонятно, кстати, всеобщее желание непременно создать свой язык, но это тема для отдельного разговора (вроде уже где-то здесь обсуждалось).

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

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

MF>Спасибо за разъяснение.

Я с удовольствием возьмусь изучать джаву и закину все остальные потуги.

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

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

Tutorial

Introduction to Resin Enterprise
Guided tutorial trail
Field persistence: A CMP bean representing a single database table.
Transactions: Using transactions to protect bean updates.
Find methods and EJB-QL: Finding a course
Creating entries: Adding and removing courses
Container relations: Students in a house
ejbSelect methods: All boys in a house
Catalog of Relations: Common relation types

Устроит?

MF>Но пощупать не знаю как. Один из указанных Вами примеров я скачал, и даже распаковал

А что делать дальше как запустить пощупать — незнаю. И где брать джаву к сожалению тоже

Ну там же все просто. Вот тебе пошаговая инструкция
1) Идешь на java.sun.com и скачиваешь J2SE SDK, J2SE SDK Documentation и J2EE. На данный момент последняя версия 1.4
2) Устанавливаешь все это хозяйство
3) Идешь на www.caucho.com и скачиваешь Resin-EE.
4) Распаковываешь архив. В каталоге bin запускаешь httpd.exe. По умолчанию оно слушает порт 8080. Если что то на этом порту весит то убей или поправь файл конфигурации. Первый раз оно будет запускаться довольно долго, так как распаковывает и компилирует все примеры. Дождись появления надписи listening port 8080 on * или что то вроде этого.
5) набираешь в IE http://127.0.0.1:8080 и через некоторое время ты должен увидеть документацию к резину.
6) Находишь секцию Tutorial и следуешь документации.

MF>Ну не так уж все и запущено

Просто не попадались мне в руки книги которые Вы читали и не учился возможно я в нужных институтах,

Ты наверное будешь удивлен но последние лет 5 по программированию я прочитал очень мало книг. Конкретно по Java только Брюса Эккеля и то не всю. В институте слово Java не произнес никто

Читайте онлайн-документацию, она рулез, поскольку от разработчика и максимально актуальна. Ну и опыт конечно.

MF>но это не уменьшает моего стремления изучить эту область, и знать!!!

Это главное.

MF>То что придется объекты отражать на плоские таблицы я думал, и даже как то пытался продумать как это сделать. Если укажите книги где можно почитать об этом — то тоже великое Вам спасибо. Особенно об OO<->Relational маппинге

К сожалению ничего на эту тему не видел. Есть несколько статей в инете, но адресов я не знаю. Поспрошай у народа, должны подсказать.

MF>Об адовой работе по деплойменту COM приложений я представление имею, как то пытался это провести на прошлоай работе. Тяжело получалось

.

В дотнете или джаве деплоймент в хорошо спроектированных приложениях обычно заключается в копировании файла(лов) в определенный каталог. Понимаешь почему СОМ+ не идеальный выбор?

MF>А вот что такое динамическая компиляция

А это правишь исходник — и у тебя сервер, отследив изменение файла, перекомпилирует класс. Резин умудряется даже рекомпильнуть единственный класс, не перезапуская приложение и получается это у него неплохо. Орион тоже рекомпилирует на ходу, но обычно это приводит к Invalid type casting

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

MF>и сколько ресурсов нужно будет положить на ее поддержку?

Ты знаешь, как не странно довольно немного. За полдня реально написать прообраз такого менеджера.

MF> Может все таки остановится на DLL

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

MF>Возмжно какая либо поэтапная работа?

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

MF>Как задавать? Будет специальное приложение (чем то похожее на виндовый ЮзерМенеджер)

Да я не про приложение. Каким образом это будет привязываться к самим объектам?

MF>Где хранить? В базе конечно

Если есть более правильный вариант, с удовольствием выслушаю и приму к сведению.

В базе? А дефолтовые значения? А как оно в базе будет организовано? А будут ли наборы прав ака роли? Возможно ли наследование ролей друг от друга? И т.д.

MF>Что значить линейно, иерархически и все такое (вернее я догадываюсь, и скороее всего будет и то и другое) очень часто будут объекты иерархические но и линейных будет немало. Хотя, если Вы расшифруете что Вы вкладывате в понятие сетевое может будет и сетевое.

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

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

Значит масштабируемость решения будет крайне низкой. х86 архитектура не позволит за разумные деньги сильно превысить возможности серверов в районе 4-5 килобаксов стоимость. Дальнейшее удорожание как правило не привносит адекватного прироста производительности.

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

Если архитектура не будет на это рассчитана то потом ты этого сделать не сможешь. Сервера приложений отличаются между собой прежде всего внутренней архитектурой. Чтобы выбрать архитектуру нужно взвесить все основные факторы. В отличие от десктопа, где косяки проектирования пользователь скорее всего не заметимт здесь архитектура играет крайне важную роль.

MF>Думаю, когда я напишу низкоуровневое ядро я вплотную займусь проектированиме объектов бизнеслогики, вот тогда и буду планировать жизденные циклы объектов.

Что ты подразумеваешь под понятием низкоуровнего ядра? Какие сервисы ты к нему относишь?

MF>Учитывая что Вы конкретно описали термины могу теперь точно сказать что большинство объектов будут меня типа Энтити, так как они будут хранится в БД, но будут и такие как стейтлес и стейтфул. Хотя это термины низкого уровня — безотносительно к безнес логике (как я это понимаю) ибо какого типа будет объект можно определить только на этапе проектировани бизнес-логики.

Ты сейчас точь в точь повторяешь основные положения J2EE

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

MF>Т.е. сдесь выплывает своеобразное разделение севера среднего уровнян на две категори ядро сервера безотносительно к бизнес-логике и собственно сервер бизнеслогики.

Ну примерно так EJB-сервера и организованы. Собственно EJB-сервер, выполняющий базовые сервисы и по контейнеру на каждое приложение. Иногда даже контейнер не являет собой нечто неизменное(библиотечное), а генерируется при деплойменте приложения, неся в себе только сервисы, реально приложением используемые.
В J2EE есть подробнейшее описание их архитектуры. Рекомендую ознакомится в любом случае, даже если будешь писать не на джаве.

AVK>>То есть тоже не думал. Плохо.
MF>А какие варианты??? Их не так ужи и много. И кстати я думал

Одина из моих мыслей — создавать специальный объект в ядре который будет через специальные интерфейсы определять версию подключаемого компонента и определять возможность его функционирования в контексте процесса сервера. Как это будет работать подробнее — пока не знаю. Но думаю это вполне реально.

А механизм наложения версий? А возможность использования CVS или SourceSafe?

MF>кеширование? — это ведь использование памяти? или например использование временных таблиц где хранятся уменьшенные выборки для работы с объектами? Все таким мне будет проще об этом думать когда я буду знать как работает мой сервер и что представляют из себя его объекты.
Неа, я речь веду прежде всего о кешах и пулах объектов. И прежде всего entity-объектов. На этом можно очень здорово выиграть в плане производительности. По результатам работы одного реального сервера могу тебе сказать что при грамотном кешировании 80-90% запросов при текущей работе (за исключением построения отчетов) попадают в память без обращения к БД. Причем в памяти висят именно те объекты которые реально используются. Кешированием выборок ты такого не добьешься, эффективность кеша на этом уровне будет заметно ниже.

AVK>>И тем не менее на дотнете можно реализовать полностью автоматическую систему конфигурирования произвольных модулей. Прообраз такой системы можно поглядеть в янусе ака RSDN@Home.

MF>Обязательно глянем. Но под конфигурированием лично я понимаю — возможность безграмотного в компьютерных понятиях бухгалтера изменить какое либо поведение системы (в переделах допущенных разработчиком). А не возможность крутообученного спеца ковыраясь в ини-файлах или в XML файлах изменить функционал системы в целом. Хотя и это я буду планировать.

По возможности так же параметрическим способом

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

MF>Я не знаю что такое ремотинг или думаю что не знаю (может я о нем знаю совсем по другому названию) если ткнете в статью MSDN где можно о нем почитать.

Здесь есть на эту тему моя статья.

MF>Хотя и вариант вебсервисов скорее всего так же не оставлю без внимания

Как вариант — гибкий вариант архитектуры с набором коннекторов для разных методов доступа.

MF>Буду стараться укладываться в тарнзакции SQL сервера (это что касается данных).

Не выйдет. mssql это транзакциолнный ресурс. Сервер же у тебя и транзактный ресурс, да еще и инициатор транзакций. Надо что то придумывать. К примеру перед выполнением защищенного транзакцией куска сериализовать состояние всех вовлеченных объектов и при откате его десериализовать. В общем здесь надо думать.

MF>Кое что чиатл про МТС, не сильно мне нравится егошный подход особенно из-за того что объекты не хранят своих состояний.

DTC? Ну это уже ближе к распределенным транзакциям.

AVK>>Смотри в форуме по дотнету. Но там есть подводные камни. Прежде всего очень кривой деплоймент и кое какие неясности с событиями и колбеками.
MF>Я так понимаю что Вы усиленно пытаетесь меня склонить к Джаве

Ни в коем случае. Скорее к дотнету

MF>Не буду Вас разочаровывать, но пока не попробую на вкус — непойму, я ж все таки хохол

А это у нас в крови

Это куда лучше чем "я буду делать так и даже не отговаривайте".

Как, я тебя еще не испугал

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

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

W>Сухое лаконичное техническое описание.

То, что доктор прописал!

В русском переводе довольно тяжелое описание. Как горькое лекарство — противно, но полезно

Но это скорее перевод.

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

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

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

AVK>

AVK>Tutorial

AVK>Introduction to Resin Enterprise
AVK>Guided tutorial trail
AVK>Field persistence: A CMP bean representing a single database table.
AVK>Transactions: Using transactions to protect bean updates.
AVK>Find methods and EJB-QL: Finding a course
AVK>Creating entries: Adding and removing courses
AVK>Container relations: Students in a house
AVK>ejbSelect methods: All boys in a house
AVK>Catalog of Relations: Common relation types

AVK>Устроит?
Незнаю попробую тогда скажу

AVK>Ну там же все просто. Вот тебе пошаговая инструкция
AVK>1) Идешь на java.sun.com и скачиваешь J2SE SDK, J2SE SDK Documentation и J2EE. На данный момент последняя версия 1.4
AVK>2) Устанавливаешь все это хозяйство
AVK>3) Идешь на www.caucho.com и скачиваешь Resin-EE.
AVK>4) Распаковываешь архив. В каталоге bin запускаешь httpd.exe. По умолчанию оно слушает порт 8080. Если что то на этом порту весит то убей или поправь файл конфигурации. Первый раз оно будет запускаться довольно долго, так как распаковывает и компилирует все примеры. Дождись появления надписи listening port 8080 on * или что то вроде этого.
AVK>5) набираешь в IE http://127.0.0.1:8080 и через некоторое время ты должен увидеть документацию к резину.
AVK>6) Находишь секцию Tutorial и следуешь документации.
Вот такая пошаговая — точно устроит

MF>>Ну не так уж все и запущено

Просто не попадались мне в руки книги которые Вы читали и не учился возможно я в нужных институтах,

AVK>Ты наверное будешь удивлен но последние лет 5 по программированию я прочитал очень мало книг. Конкретно по Java только Брюса Эккеля и то не всю. В институте слово Java не произнес никто

Читайте онлайн-документацию, она рулез, поскольку от разработчика и максимально актуальна. Ну и опыт конечно.

Чтож буду надеятся что и мне удасться так изучить материал

Вроде тоже не меньше 5 лет программированием занимаюсь. И угораздило меня встрять в эту 1С. Попортила мне все

MF>>Как задавать? Будет специальное приложение (чем то похожее на виндовый ЮзерМенеджер)

AVK>Да я не про приложение. Каким образом это будет привязываться к самим объектам?
Ну как — вообще то думал будет отедльная таблица в которой будут идентификаторы объектов сопоставлятся правам доступа (предполагается что каждый объект будет иметь уникальный признак в пределах сервера (или серверов). Ну и специальный сервис будет проверять права пользователя на совпадение с правами объекта. Где то так

MF>>Где хранить? В базе конечно

Если есть более правильный вариант, с удовольствием выслушаю и приму к сведению.

AVK>В базе? А дефолтовые значения? А как оно в базе будет организовано? А будут ли наборы прав ака роли? Возможно ли наследование ролей друг от друга? И т.д.
Ну в этой же базе будут своеобразные метаданные — которые будут описывать объекты. Вот в этих метаданных и будут дефолтные объекты.
Над ролями я еще думаю. Будет группа, пользователей, а будет ли группа обладать определенной ролью — надо придумать как

MF>>Что значить линейно, иерархически и все такое (вернее я догадываюсь, и скороее всего будет и то и другое) очень часто будут объекты иерархические но и линейных будет немало. Хотя, если Вы расшифруете что Вы вкладывате в понятие сетевое может будет и сетевое.

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

В голове пока это не помещается никак

Вот если увижу реальную необходимость — такого графа. Буду думать а пока не представляю себе реального выражения такого подхода.

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

AVK>Значит масштабируемость решения будет крайне низкой. х86 архитектура не позволит за разумные деньги сильно превысить возможности серверов в районе 4-5 килобаксов стоимость. Дальнейшее удорожание как правило не привносит адекватного прироста производительности.
В последствии будем думать как это работает

Скорее всего разные компоненты сервера будут работать на разных физических серверах. И если буду использовать COM — то это несложно

Хотя чуствую подводных комней в таком подходе больше чем достаточно.

MF>>Думаю, когда я напишу низкоуровневое ядро я вплотную займусь проектированиме объектов бизнеслогики, вот тогда и буду планировать жизденные циклы объектов.

AVK>Что ты подразумеваешь под понятием низкоуровнего ядра? Какие сервисы ты к нему относишь?
Обеспечение безопасности, обработка объектов, механизмы передачи наборов данных. Регистрация объектов, описание объектов. Вообщем работа с метаданными. Неболее.

AVK>>>То есть тоже не думал. Плохо.
MF>>А какие варианты??? Их не так ужи и много. И кстати я думал

MF>>кеширование? — это ведь использование памяти? или например использование временных таблиц где хранятся уменьшенные выборки для работы с объектами? Все таким мне будет проще об этом думать когда я буду знать как работает мой сервер и что представляют из себя его объекты.
AVK>Неа, я речь веду прежде всего о кешах и пулах объектов. И прежде всего entity-объектов. На этом можно очень здорово выиграть в плане производительности. По результатам работы одного реального сервера могу тебе сказать что при грамотном кешировании 80-90% запросов при текущей работе (за исключением построения отчетов) попадают в память без обращения к БД. Причем в памяти висят именно те объекты которые реально используются. Кешированием выборок ты такого не добьешься, эффективность кеша на этом уровне будет заметно ниже.
Т.е. должен быть какой то сервис определяющий выгружать объект из памяти или нет? На основании законов конкретной бизнес задачи? Ну думаю это тоже несложно сделать.

AVK>>>И тем не менее на дотнете можно реализовать полностью автоматическую систему конфигурирования произвольных модулей. Прообраз такой системы можно поглядеть в янусе ака RSDN@Home.
Ваше глянь — для меня непосильный труд — Вы только представьте человеку работавшему на 1С и на Delphi — без какого либо вводного теоретического курса ломануться смотреть исходники программы которые занимают наверняка не одну сотню килобайт

MF>>Обязательно глянем. Но под конфигурированием лично я понимаю — возможность безграмотного в компьютерных понятиях бухгалтера изменить какое либо поведение системы (в переделах допущенных разработчиком). А не возможность крутообученного спеца ковыраясь в ини-файлах или в XML файлах изменить функционал системы в целом. Хотя и это я буду планировать.

По возможности так же параметрическим способом

AVK>Я пока не говорю совсем о внешнем интерфейсе конфигурирования. Речь о параметрах для писателя сервисов к серверу и собственно приложений для него. Автоматическая система конфигурирования сводиться к тому что ты просто говоришь что вот в этом свойстве хранится некий произвольный класс, хранящий твою конфигурацию. Все остальное берет на себя специальный сервис.
Ну это похоже на зачатки искуственного интеллекта. Как должен сервис обучаться??? Если я позже создаю модуль о котором сервис и понятия не имел, и меняю принципы конфигурирования??? Что должен делать сервис даже если я ему дам на вход какйнибудь файл?

MF>>Я не знаю что такое ремотинг или думаю что не знаю (может я о нем знаю совсем по другому названию) если ткнете в статью MSDN где можно о нем почитать.

AVK>Здесь есть на эту тему моя статья.
Вот бы ссылку

MF>>Хотя и вариант вебсервисов скорее всего так же не оставлю без внимания

AVK>Как вариант — гибкий вариант архитектуры с набором коннекторов для разных методов доступа.

MF>>Буду стараться укладываться в тарнзакции SQL сервера (это что касается данных).

AVK>Не выйдет. mssql это транзакциолнный ресурс. Сервер же у тебя и транзактный ресурс, да еще и инициатор транзакций. Надо что то придумывать. К примеру перед выполнением защищенного транзакцией куска сериализовать состояние всех вовлеченных объектов и при откате его десериализовать. В общем здесь надо думать.
Будем думать

AVK>Это куда лучше чем "я буду делать так и даже не отговаривайте".

AVK>Как, я тебя еще не испугал

Испугал??? Чем?

... << RSDN@Home 1.0 beta 6a >>

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

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

AVK>

AVK>Tutorial

AVK>Introduction to Resin Enterprise
AVK>Guided tutorial trail
AVK>Field persistence: A CMP bean representing a single database table.
AVK>Transactions: Using transactions to protect bean updates.
AVK>Find methods and EJB-QL: Finding a course
AVK>Creating entries: Adding and removing courses
AVK>Container relations: Students in a house
AVK>ejbSelect methods: All boys in a house
AVK>Catalog of Relations: Common relation types

AVK>Устроит?
Незнаю попробую тогда скажу

MF>>Ну не так уж все и запущено

Вроде тоже не меньше 5 лет программированием занимаюсь. И угораздило меня встрять в эту 1С. Попортила мне все

MF>>Где хранить? В базе конечно

По возможности так же параметрическим способом

Испугал??? Чем?

... << RSDN@Home 1.0 beta 6a >>

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

AVK>>Это уже тонкий клиент.
MF>Да я вообщем это и понимаю

.

Может оказаться, что и свой собственный придётся делать. Здесь нужно будет определиться — будет клиент обращаться к конкретным методам прикладных объектов (т.е. — будет он так или иначе, но зависимым от приложения) или будет взаимодействовать с сервером по какому-то своему протоколу, независимому от прикладной конфигурации. Второй вариант привлекательнее, но и сложнее.

AVK>>Судя по твоему выбору тебе нужен OO<->Relational mapping. Создание такого меппинга так чтобы он был не более чем на порядок медленнее обычного обращения на групповых операциях нетривиальная задача в общем то.

MF>Просто не попадались мне в руки книги которые Вы читали и не учился возможно я в нужных институтах, но это не уменьшает моего стремления изучить эту область, и знать!!!

В институтах этому, по-моему, ещё не учат. Ну, во всяком случае — непосредственно.

MF>То что придется объекты отражать на плоские таблицы я думал, и даже как то пытался продумать как это сделать. Если укажите книги где можно почитать об этом — то тоже великое Вам спасибо. Особенно об OO<->Relational маппинге

Посмотри для начала на RSDN в разделе Ресурсы/Ссылки/Object-Oriented. Я уже упоминал его в первом ответе.

Мэппинг — достаточно сложная проблема и одна из основных. Тут беда в том, что в открытой сети можно откопать в основном материалы на тему статического отображения (класс — определённая структура таблиц) и полуавтоматической реализации CRUD (т.е. — набора операций Create/Retrive/Update/Delete), а это только базовые вещи на самом деле. (Остальное приватом, если интересно

)

Я бы вообще выделил четыре технологических "краеугольных камня" (пусть коллеги меня поправят) :

— Модель бизнес-объекта и его жизненного цикла;
— Security;
— Объектно-реляционное отображение;
— Контроль версий.

MF> это всетаки мой первый проект [...] Возмжно какая либо поэтапная работа?

Тяжеловатый он для первого проекта, тут я с остальными участниками соглашусь.

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

AVK>>>>6) Схема идентификации и аутентификации
AVK>>Низзя. Это очень часто встречающаяся ошибка. Пока ты не продумаешь базовые вопросы нельзя писать ни одной строчки кода, иначе потом придется все переписывать.
MF>Я имелл ввиду что сначала выспрошу у народа, выясню как а потом приступлю к кодированию, но процесс выспрашивания это уже будет фаза "приступлю к реализации".

AVK совершенно прав. Хотя бы на уровне моделей нужно составить представление об архитектуре системы. Иначе утонешь в постоянных переделках того, что будет казаться "уже почти готовым".

MF>Политика смешанная Группы+Пользователи+Уровень

Ну вот, на самом главном ты плаваешь.

Какой рисовалкой пользоваться — отдельным приложением, или, скажем, модулем, написанным как часть твоей системы — это уже второстепенно, хотя и не скажу, что "неважно".

Проблема в том, какова детализация объектов доступа. Т.е. — собираешься ли ты управлять доступом к полям и методам конкретного экземпляра или ограничишься классами? Или примешь промежуточный вариант — ограничение доступа на поля/методы класса? Можно по-любому. Разница — в сложности реализации и возможных дальнейших ограничениях.

MF>Что значить линейно, иерархически и все такое (вернее я догадываюсь, и скороее всего будет и то и другое) очень часто будут объекты иерархические но и линейных будет немало. Хотя, если Вы расшифруете что Вы вкладывате в понятие сетевое может будет и сетевое.

AVK>>Схема распределения нагрузки на несколько серверов. Хорошие сервера приложений как правило умеют работать в составе кластера серверов, динамически распределяя между ними нагрузку, а иногда еще и бессбойная (ну или хотя бы со сбоем только у его клиентов) изоляция отказавшего сервера с непрерывностью функционирования кластера в целом.

MF>[Распределение нагрузки] Так что этот вопрос просто исключаем из рассмотрения (я думаю большого вреда от этого небудет)

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

AVK>>Посмотри описание EJB — идея то она везде общая. А планировать жизненные циклы нужно обязательно, это одна из основных характеристик сервера приложений.
MF>Думаю, когда я напишу низкоуровневое ядро я вплотную займусь проектированиме объектов бизнеслогики, вот тогда и буду планировать жизденные циклы объектов.

НИ В КОЕМ СЛУЧАЕ ТАК НЕ ДЕЛАЙ! Модель жизненного цикла объекта разрабатывается изначально — это почти что альфа и омега! То есть, сначала ты должен определить возможные виды жизненных циклов объектов (аналогично, скажем, STATEFUL и STATELESS), потом — реализовать необходимую их поддержку в ядре, а только потом, исходя из их возможных комбинаций — проектировать реализацию бизнес-логики. Только не наоборот.

Под моделью ЖЦ я понимаю здесь summary ответов на примерно следующие вопросы:

— Что представляет из себя бизнес-объект? Каковы вариации типов бизнес-объектов?
— Возможно ли их совмещение через наследование, агрегацию? Если да, то как?
— Чем и при каких условиях создаются объекты в памяти? Как отслеживаются?
— Чем и когда они удаляются из памяти? Из базы данных?
— Что происходит с объектами при транзакциях?

Кстати, в литературе ты встретишь разные термины для обозначения одних и тех же вещей. Например, stateless подобен transitive в терминологии Шлеера, а stateful — persistable (аналогично).

MF>Учитывая что Вы конкретно описали термины могу теперь точно сказать что большинство объектов будут меня типа Энтити, так как они будут хранится в БД, но будут и такие как стейтлес и стейтфул. Хотя это термины низкого уровня — безотносительно к безнес логике (как я это понимаю) ибо какого типа будет объект можно определить только на этапе проектировани бизнес-логики.

MF>Т.е. сдесь выплывает своеобразное разделение севера среднего уровнян на две категори ядро сервера безотносительно к бизнес-логике и собственно сервер бизнеслогики.

Не совсем так: сервер бизнес-логики, это скорее совокупность ядра и объектов бизнес-логики. Впрочем, это уже терминологическая игра.

AVK>>>>9) Механизм контроля версий.
AVK>>То есть тоже не думал. Плохо.
MF>А какие варианты??? Их не так ужи и много. И кстати я думал

), только пока что не полно.

Одна из задач, которую нужно будет решить — как обеспечить отсутствие конфликтов объектов разных версий. От неё потянутся "хвосты" на мэппинг. Другая задача — перезагрузка объектов "на лету" (понадобится для случая сервера, работающего в режиме 24x7).

AVK>>>>10) Алгоритмы кеширования.
AVK>>Без этого производительность твоего сервера будет плачевной. А если еще и OO-Relational меппинг наличествует, то производительность без кеша объектов будет просто никакая.
MF>кеширование? — это ведь использование памяти? или например использование временных таблиц где хранятся уменьшенные выборки для работы с объектами? Все таким мне будет проще об этом думать когда я буду знать как работает мой сервер и что представляют из себя его объекты.

Вот тут AVK тоже совершенно прав. Кеширование служит для того, чтобы можно было в каких-то случаях избежать обращений к БД (так что, про временные таблицы — забудь). Ключ вот в чём — если обработка объектов выполняется только в памяти, то в худшем случае при групповой операции каждый объект последовательно "поднимается" в память (а это каждый раз — select) и потом отправляется в БД. Производительность усвистит вниз до непотребных величин. Поэтому нужно продумать схему кэширования. Возможно — предварительное чтение объектов, возможно — групповое чтение обрабатываемого набора и такая же групповая запись. Можно найти другие варианты.

Кстати, ты прав тоже — это действительно использование памяти.

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

AVK>>Да, совсем забыл — надо еще продумать механизм транзакций, в том числе и распределенных.
MF>Буду стараться укладываться в тарнзакции SQL сервера (это что касается данных). Ну а там где это будет невозможно например транзакция безнес-логики

Буду что то выдумывать

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

Тут скорее наоборот — нужно уложить транзакции SQL-сервера в твою модель транзакций, которая должна быть объектной. Кстати, модель транзакций тесно связана с моделью жизненного цикла объекта.

Если немного обобщить, то относись к SQL-серверу (любому), как не более чем к средству хранения данных. Сразу снимется часть проблем с поиском оптимального решения с точки зрения MS-SQL и твоего ядра. Кстати, в перспективе, сможешь использовать и MTS.

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

AVK>>В сжатые сроки это сколько конкретно?
MF>Хочется начать уже завтра. Но это к сожалению невозможно

. Хочу весь этот мандраж по выяснению возможностей и определению языка реализации уместить в месяца 3-4. Ну а весь проект в 1-2 года.

Ну, по части 1-2 лет... всё-таки 1 или 2 года? И ещё — 1-2 года на что? На псевдоуниверсальную АСУ? Это не меньше двух лет (учти, тебе ещё аналитиков набирать и прикладников обучать). На ядро? Год в твоём случае — впритык (с отладкой и минимальными рабочими приложениями). По моему опыту (псхпп IT), если через год у тебя вообще ничего не будет работать — пиши пропало. Тебе просто не поверят и другого года просто не дадут.

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

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

AVK>>>Это уже тонкий клиент.
MF>>Да я вообщем это и понимаю

.

ГВ>Может оказаться, что и свой собственный придётся делать. Здесь нужно будет определиться — будет клиент обращаться к конкретным методам прикладных объектов (т.е. — будет он так или иначе, но зависимым от приложения) или будет взаимодействовать с сервером по какому-то своему протоколу, независимому от прикладной конфигурации. Второй вариант привлекательнее, но и сложнее.
А бывают не свои собственные???? Я чето не понимаю? Хотя да

Бывают — IE — это не мой собственный, согласен

Но! Это он будет последний для кого я буду писать

) Так вот мне кажется — хотя и ошибаюсь

MF>>То что придется объекты отражать на плоские таблицы я думал, и даже как то пытался продумать как это сделать. Если укажите книги где можно почитать об этом — то тоже великое Вам спасибо. Особенно об OO<->Relational маппинге

ГВ>Посмотри для начала на RSDN в разделе Ресурсы/Ссылки/Object-Oriented. Я уже упоминал его в первом ответе.
Глянул — но там все на агнлицком как минимум. Так что буду усердно разбиратся когда дойду до этого в своих конструкторских мучениях.

ГВ>Мэппинг — достаточно сложная проблема и одна из основных. Тут беда в том, что в открытой сети можно откопать в основном материалы на тему статического отображения (класс — определённая структура таблиц) и полуавтоматической реализации CRUD (т.е. — набора операций Create/Retrive/Update/Delete), а это только базовые вещи на самом деле. (Остальное приватом, если интересно

)

Конечно интересно. Просто, у меня такая масса вопросов, что проще наверно звонить, чем писать

У меня уже пальцы отваливаюстя. Это притом что у меня клава эргономичная,

да и печатаю вроде десятью пальцами

ГВ>Я бы вообще выделил четыре технологических "краеугольных камня" (пусть коллеги меня поправят) :

ГВ>- Модель бизнес-объекта и его жизненного цикла;
ГВ>- Security;
ГВ>- Объектно-реляционное отображение;
ГВ>- Контроль версий.

MF>> это всетаки мой первый проект [...] Возмжно какая либо поэтапная работа?
ГВ>Тяжеловатый он для первого проекта, тут я с остальными участниками соглашусь.

Все что легче этого я уже съел

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

ГВ>А с поэтапностью легче определяться, когда более или менее ясно прописал всё (или почти всё) на бумаге. Кстати, да — схему (в смысле — алгоритмы для людей и компьютера) деплоймента нужно продумывать тоже сразу.
Ага, я для этого дела даже книжку купил Крейга Лармана. UML и шаблоны проектирования. Но как то невлезает она в мою хохляцкую голову без практики, а практикой заняться не могу, нет учителя которому можно дать на проверку задание

MF>>Политика смешанная Группы+Пользователи+Уровень

ГВ>Ну вот, на самом главном ты плаваешь.

Какой рисовалкой пользоваться — отдельным приложением, или, скажем, модулем, написанным как часть твоей системы — это уже второстепенно, хотя и не скажу, что "неважно".

ГВ>Проблема в том, какова детализация объектов доступа. Т.е. — собираешься ли ты управлять доступом к полям и методам конкретного экземпляра или ограничишься классами? Или примешь промежуточный вариант — ограничение доступа на поля/методы класса? Можно по-любому. Разница — в сложности реализации и возможных дальнейших ограничениях.
Если честно, то хочу завязаться с SECURITY по самые помидоры, но переживаю как бы не загубило оно мне проект, по скоростным показателям. А какой компромис выбрать -незнаю, ибо не знаю механизмов реализации различных спобов обсуждавшихся ранее. Одно точно, не хочу делать это средствами SQL

вернее полностью (частично все таки придется)

MF>>Что значить линейно, иерархически и все такое (вернее я догадываюсь, и скороее всего будет и то и другое) очень часто будут объекты иерархические но и линейных будет немало. Хотя, если Вы расшифруете что Вы вкладывате в понятие сетевое может будет и сетевое.

AVK>>>Схема распределения нагрузки на несколько серверов. Хорошие сервера приложений как правило умеют работать в составе кластера серверов, динамически распределяя между ними нагрузку, а иногда еще и бессбойная (ну или хотя бы со сбоем только у его клиентов) изоляция отказавшего сервера с непрерывностью функционирования кластера в целом.

MF>>[Распределение нагрузки] Так что этот вопрос просто исключаем из рассмотрения (я думаю большого вреда от этого небудет)

ГВ>По возможности, его надо проработать хотя бы в общих чертах — как переносятся соединения с пользователем, как передаются сотояния объектов между серверами кластера, как выполняется синхронизация кэша, как управлять блокировками. Кстати, распределения нагрузки ты не увидишь (сможешь только предполагать что-то), пока не попытаешься её реально распределить по нескольким физическим серверам.
Вот именно, но после того как Вы сказали о некоторых деталях этого распределения — то можно уже и задуматься.

AVK>>>Посмотри описание EJB — идея то она везде общая. А планировать жизненные циклы нужно обязательно, это одна из основных характеристик сервера приложений.
MF>>Думаю, когда я напишу низкоуровневое ядро я вплотную займусь проектированиме объектов бизнеслогики, вот тогда и буду планировать жизденные циклы объектов.

ГВ>НИ В КОЕМ СЛУЧАЕ ТАК НЕ ДЕЛАЙ! Модель жизненного цикла объекта разрабатывается изначально — это почти что альфа и омега! То есть, сначала ты должен определить возможные виды жизненных циклов объектов (аналогично, скажем, STATEFUL и STATELESS), потом — реализовать необходимую их поддержку в ядре, а только потом, исходя из их возможных комбинаций — проектировать реализацию бизнес-логики. Только не наоборот.
Да??? А как я буду определять модель жизненного цикла объекта "шестеренка" если на первом этапе я не собираюсь приступать к реализации бизнес логики, а хочу все силы кинуть на формирование ядра???

ГВ>Под моделью ЖЦ я понимаю здесь summary ответов на примерно следующие вопросы:

ГВ>- Что представляет из себя бизнес-объект? Каковы вариации типов бизнес-объектов?
Очень абстрактный вопрос — очень тяжелоно на него ответить, очитвая что бизнес объектов на предприятии среднего уровня около 1000 и более

Если хорошо поискать конечно.
ГВ>- Возможно ли их совмещение через наследование, агрегацию? Если да, то как?
Думаю возможно, один из аргументов по которым хочу писать свою систему — это возможность управления наследованием и агрегацией (я лично очень сомневаюсь что в 8 такая фича будет)
ГВ>- Чем и при каких условиях создаются объекты в памяти? Как отслеживаются?
Вот этот вопрос я обдумывал, для каждой категории бизнесобъектов будет своеобразный "менеджер" который будет заниматся их созданием уничтожением, и наверное и маппингом, и даже кешированием.
ГВ>- Чем и когда они удаляются из памяти? Из базы данных?
ГВ>- Что происходит с объектами при транзакциях?
Скорее всего как уже предлагалось ранее будет какая нибудь сериализация при транзакциях с контролем safepoint-ов.

ГВ>Кстати, в литературе ты встретишь разные термины для обозначения одних и тех же вещей. Например, stateless подобен transitive в терминологии Шлеера, а stateful — persistable (аналогично).

MF>>Учитывая что Вы конкретно описали термины могу теперь точно сказать что большинство объектов будут меня типа Энтити, так как они будут хранится в БД, но будут и такие как стейтлес и стейтфул. Хотя это термины низкого уровня — безотносительно к безнес логике (как я это понимаю) ибо какого типа будет объект можно определить только на этапе проектировани бизнес-логики.

MF>>Т.е. сдесь выплывает своеобразное разделение севера среднего уровнян на две категори ядро сервера безотносительно к бизнес-логике и собственно сервер бизнеслогики.

ГВ>Не совсем так: сервер бизнес-логики, это скорее совокупность ядра и объектов бизнес-логики. Впрочем, это уже терминологическая игра.
Согласен.

AVK>>>>>9) Механизм контроля версий.
AVK>>>То есть тоже не думал. Плохо.
MF>>А какие варианты??? Их не так ужи и много. И кстати я думал

), только пока что не полно.

ГВ>Одна из задач, которую нужно будет решить — как обеспечить отсутствие конфликтов объектов разных версий. От неё потянутся "хвосты" на мэппинг. Другая задача — перезагрузка объектов "на лету" (понадобится для случая сервера, работающего в режиме 24x7).
Да я уже думал что будет два типа объектов поддерживающих хотсвап и неподдерживающих. Т.е. если объект поддерживает хотсвап то сервис обновелния загружает его в систему сразу после прекращения использования всех его экзепляров. Если не поддерживает, производится перезагрузка сервера, холодный старт, пересборка или еще чего либо там.

AVK>>>>>10) Алгоритмы кеширования.
AVK>>>Без этого производительность твоего сервера будет плачевной. А если еще и OO-Relational меппинг наличествует, то производительность без кеша объектов будет просто никакая.
MF>>кеширование? — это ведь использование памяти? или например использование временных таблиц где хранятся уменьшенные выборки для работы с объектами? Все таким мне будет проще об этом думать когда я буду знать как работает мой сервер и что представляют из себя его объекты.

ГВ>Вот тут AVK тоже совершенно прав. Кеширование служит для того, чтобы можно было в каких-то случаях избежать обращений к БД (так что, про временные таблицы — забудь). Ключ вот в чём — если обработка объектов выполняется только в памяти, то в худшем случае при групповой операции каждый объект последовательно "поднимается" в память (а это каждый раз — select) и потом отправляется в БД. Производительность усвистит вниз до непотребных величин. Поэтому нужно продумать схему кэширования. Возможно — предварительное чтение объектов, возможно — групповое чтение обрабатываемого набора и такая же групповая запись. Можно найти другие варианты.
Да я над этим думал, просто не называл это для себя кешированием, и возможно не так акцентировал внимание как следовало бы. Теперь после ваших подсказок, все будет слегка по другому

ГВ>Кстати, ты прав тоже — это действительно использование памяти.

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

AVK>>>Да, совсем забыл — надо еще продумать механизм транзакций, в том числе и распределенных.
MF>>Буду стараться укладываться в тарнзакции SQL сервера (это что касается данных). Ну а там где это будет невозможно например транзакция безнес-логики

Буду что то выдумывать

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

ГВ>Тут скорее наоборот — нужно уложить транзакции SQL-сервера в твою модель транзакций, которая должна быть объектной. Кстати, модель транзакций тесно связана с моделью жизненного цикла объекта.

ГВ>Если немного обобщить, то относись к SQL-серверу (любому), как не более чем к средству хранения данных. Сразу снимется часть проблем с поиском оптимального решения с точки зрения MS-SQL и твоего ядра. Кстати, в перспективе, сможешь использовать и MTS.

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

AVK>>>В сжатые сроки это сколько конкретно?
MF>>Хочется начать уже завтра. Но это к сожалению невозможно

. Хочу весь этот мандраж по выяснению возможностей и определению языка реализации уместить в месяца 3-4. Ну а весь проект в 1-2 года.

ГВ>Ну, по части 1-2 лет... всё-таки 1 или 2 года? И ещё — 1-2 года на что? На псевдоуниверсальную АСУ? Это не меньше двух лет (учти, тебе ещё аналитиков набирать и прикладников обучать). На ядро? Год в твоём случае — впритык (с отладкой и минимальными рабочими приложениями). По моему опыту (псхпп IT), если через год у тебя вообще ничего не будет работать — пиши пропало. Тебе просто не поверят и другого года просто не дадут.
Это я понимаю, поэтому и продолжаем писать на 1С, а не "уходим под лед"

... << RSDN@Home 1.0 beta 6a >>

Пожалуйста, оставляйте в ответах только необходимую часть исходного сообщения. Не стоит цитировать его целиком.

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

ГВ>Может оказаться, что и свой собственный придётся делать. Здесь нужно будет определиться — будет клиент обращаться к конкретным методам прикладных объектов (т.е. — будет он так или иначе, но зависимым от приложения) или будет взаимодействовать с сервером по какому-то своему протоколу, независимому от прикладной конфигурации. Второй вариант привлекательнее, но и сложнее.

Ещё можно свою операционку написать, тоже будет очень привлекательно

ГВ>Я бы вообще выделил четыре технологических "краеугольных камня" (пусть коллеги меня поправят) :

ГВ>- Модель бизнес-объекта и его жизненного цикла;
ГВ>- Security;
ГВ>- Объектно-реляционное отображение;
ГВ>- Контроль версий.

Я бы ещё добавил мониторинг, статистику и логирование, которые нужно зашивать в сервер изначально. Под хорошей нагрузкой — это единственный способ понять что происходит в системе.

MF>>[Распределение нагрузки] Так что этот вопрос просто исключаем из рассмотрения (я думаю большого вреда от этого небудет)

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

ГВ>По возможности, его надо проработать хотя бы в общих чертах — как переносятся соединения с пользователем, как передаются сотояния объектов между серверами кластера, как выполняется синхронизация кэша, как управлять блокировками. Кстати, распределения нагрузки ты не увидишь (сможешь только предполагать что-то), пока не попытаешься её реально распределить по нескольким физическим серверам.

На этих задачах можно состариться и так и не увидеть своё детище в производстве. Железный, проверенный способ поддержки распределённой нагрузки — stateless модель для объектов хранимых в базе данных. Stateful только для очень редкоизменяемых объектов.

ГВ>Под моделью ЖЦ я понимаю здесь summary ответов на примерно следующие вопросы:

ГВ>- Что представляет из себя бизнес-объект? Каковы вариации типов бизнес-объектов?
ГВ>- Возможно ли их совмещение через наследование, агрегацию? Если да, то как?
ГВ>- Чем и при каких условиях создаются объекты в памяти? Как отслеживаются?
ГВ>- Чем и когда они удаляются из памяти? Из базы данных?
ГВ>- Что происходит с объектами при транзакциях?

Так же обрати внимание на частоту использования объектов и стоит ли их вообще держать в памяти или кешировать. Может получиться так что твоя память или кеш будет забита объектами, которые долгое время никому не нужны и смысла в применении подобных вещей нет. Так обычно просиходит с большинством рабочих объектов, таких как проводка в бухгалтерии или счёт кастомера. Здесь тебе как раз и поможет статистика и мониторинг, о которых я говорил ранее.

ГВ>Одна из задач, которую нужно будет решить — как обеспечить отсутствие конфликтов объектов разных версий. От неё потянутся "хвосты" на мэппинг. Другая задача — перезагрузка объектов "на лету" (понадобится для случая сервера, работающего в режиме 24x7).

stateless, только stateless.

ГВ>Если немного обобщить, то относись к SQL-серверу (любому), как не более чем к средству хранения данных. Сразу снимется часть проблем с поиском оптимального решения с точки зрения MS-SQL и твоего ядра. Кстати, в перспективе, сможешь использовать и MTS.

Мда, советик ещё тот

SQL сервер — сердце системы и к нему нужно относится бережно и трепетно, лелеять и холить. Неоптимальная организация данных или неоптимальные запросы могут просадить всю систему так, что не помогут и десяток апп-серверов. Что можно и нужно сделать — это выделить всю работу с базой в отдельный слой и уже даже на уровне ядра не иметь дела не только с именами таблиц, но даже с именами полей. Только через структуры данных и/или типизированные датасеты. Это мероприятие следует рассматривать как гигиеническое и так к нему и относиться. Ты же в конце концов не спрашиваешь себя зачем ты каждый день чистишь зубы, просто так надо

Ещё немного от себя из своего э... ГВ знает.

1. Разработка должна вестись на реально-предполагаемых объёмах данных, в противном случае поведение системы во время эксплуатации будет непредсказуемым и её ресурс производительности будет быстро исчерпан в совершенно неожиданных местах.

2. Для всех пакетных операций обработки данных бизнес-уровень идёт лесом и они выполняются только сохранёнными процедурами самого SQL сервера. В противном случае — медленная смерть при росте объёма данных. SQL сервер справляется с такими задачами в разы, а иногда и десятки раз быстрее. К тому же их можно повесить на расписание в часы, когда сервер не загружен основными задачами.

3. Этапность разработки и максимально короткий цикл между этапами, хотя при разработки подобных вещей с нуля это совсем не просто.

4. Unit-тестирование.

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

IT>Я бы ещё добавил мониторинг, статистику и логирование, которые нужно зашивать в сервер изначально. Под хорошей нагрузкой — это единственный способ понять что происходит в системе.
Во!!! А я то думаю что еще впихнуть в сервер Статистику!!! Вот это та еще задача. Спасибо Вам большое много уважаемый IT!!!

IT>Кластеры и лоадбалансеры [......] Дороже могут быть только ошибке в дизайне базы данных.

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

IT>На этих задачах можно состариться и так и не увидеть своё детище в производстве. Железный, проверенный способ поддержки распределённой нагрузки — stateless модель для объектов хранимых в базе данных. Stateful только для очень редкоизменяемых объектов.

СтайтЛесс — это ведь объекты не хранящие своего состояния так? Т.е. те которые загружаются каждый раз из базы если с ним необходиом сделать какое либо действие, и уничтожающиеся после окончания этого действия? Так я понимаю? Т.е. основная нагрузка ложится на канал между АППСеврером и SQL сервером? Если у меня большое количество клиентов будет работать с этими объектами? то как же тогда выполнять кеширование??? И не будет ли узким местом слишком частые запросы к SQL серверу?

ГВ>>Одна из задач, которую нужно будет решить — как обеспечить отсутствие конфликтов объектов разных версий.[....]
IT>stateless, только stateless.
Ну если так, то да

Но нафиг тогда иметь объекты (и средний уровень вообще, несчитаю секюрити канечно

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

ГВ>>Если немного обобщить, то относись к SQL-серверу (любому), как не более чем к средству хранения данных. Сразу снимется часть проблем с поиском оптимального решения с точки зрения MS-SQL и твоего ядра. Кстати, в перспективе, сможешь использовать и MTS.

IT>Мда, советик ещё тот

IT>SQL сервер — сердце системы и к нему нужно относится бережно и трепетно, лелеять и холить. Неоптимальная организация данных или неоптимальные запросы могут просадить всю систему так, что не помогут и десяток апп-серверов. Что можно и нужно сделать — это выделить всю работу с базой в отдельный слой и уже даже на уровне ядра не иметь дела не только с именами таблиц, но даже с именами полей. Только через структуры данных и/или типизированные датасеты. Это мероприятие следует рассматривать как гигиеническое и так к нему и относиться. Ты же в конце концов не спрашиваешь себя зачем ты каждый день чистишь зубы, просто так надо

Поддерживаю, даже когда пишу на 1С трачу не один день на вылизывание SQL запросов (я работаю напрямую, забил болт на запросы 1С

)

Со всем остальным согласен, принял к сведению. Буду использовать. Весьма признателен и за следующие советы и подсказки.

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

... << RSDN@Home 1.0 beta 6a >>

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

MF>СтайтЛесс — это ведь объекты не хранящие своего состояния так? Т.е. те которые загружаются каждый раз из базы если с ним необходиом сделать какое либо действие, и уничтожающиеся после окончания этого действия? Так я понимаю? Т.е. основная нагрузка ложится на канал между АППСеврером и SQL сервером? Если у меня большое количество клиентов будет работать с этими объектами? то как же тогда выполнять кеширование??? И не будет ли узким местом слишком частые запросы к SQL серверу?
Нет, тут дело в восприятии объектов. Stateless объекты лучше воспринимать как глаголы, а не как существительные. Т.е. вместо объекта "рейс", у которого есть множество объектов-мест, у каждого из которых можно изменить признак "зарезервирован", и даже вместо объекта "рейс", у которого есть свойство "количество свободных мест", делается объект "резервирование билета". У него есть метод "поехали" — который и выполняет глагол, и, возможно, набор свойств, которые описывают как выполнять это главное действие. Типа номера рейса, класса салона... Для его работы вообще не надо ничего кэшировать. В случае грамотно спроектированного нижнего уровня выполнение метода "поехали" может свестись к вызову "update reservation set free_seats = free_seats-1 where reservation_id='S73337'", который вообще не требует подъема чего-либо в память, а соответствие количества проданных билетов количеству мест самолета гарантируется check constraint на free_seats>=0.
IT>>stateless, только stateless.

... << RSDN@Home 1.0 beta 6 >>

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

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

S>Нет, тут дело в восприятии объектов. Stateless объекты лучше воспринимать как глаголы, а не как существительные. Т.е. вместо объекта "рейс", у которого есть множество объектов-мест, у каждого из которых можно изменить признак "зарезервирован", и даже вместо объекта "рейс", у которого есть свойство "количество свободных мест", делается объект "резервирование билета". У него есть метод "поехали" — который и выполняет глагол, и, возможно, набор свойств, которые описывают как выполнять это главное действие. Типа номера рейса, класса салона... Для его работы вообще не надо ничего кэшировать. В случае грамотно спроектированного нижнего уровня выполнение метода "поехали" может свестись к вызову "update reservation set free_seats = free_seats-1 where reservation_id='S73337'", который вообще не требует подъема чего-либо в память, а соответствие количества проданных билетов количеству мест самолета гарантируется check constraint на free_seats>=0.
Но ведь объекты существительные так же нужны? Или по Вашему мнению от них можно отказаться?
S>

... << RSDN@Home 1.0 beta 6a >>

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

S>Нет, тут дело в восприятии объектов. Stateless объекты лучше воспринимать как глаголы, а не как существительные. Т.е. вместо объекта "рейс", у которого есть множество объектов-мест, у каждого из которых можно изменить признак "зарезервирован", и даже вместо объекта "рейс", у которого есть свойство "количество свободных мест", делается объект "резервирование билета". У него есть метод "поехали" — который и выполняет глагол, и, возможно, набор свойств, которые описывают как выполнять это главное действие. Типа номера рейса, класса салона... Для его работы вообще не надо ничего кэшировать. В случае грамотно спроектированного нижнего уровня выполнение метода "поехали" может свестись к вызову "update reservation set free_seats = free_seats-1 where reservation_id='S73337'", который вообще не требует подъема чего-либо в память, а соответствие количества проданных билетов количеству мест самолета гарантируется check constraint на free_seats>=0.

Именно так.

Вообще ООП модель объектов имея неоспоримые преимущества, страдает рядом серьёзных недостатков, которые выливаются в результате в торомоза и большую сложность и запутанность системы, порой совершенно неоправданно. Пример, объект "Гайка номер M56 инвентарный номер Г560032345 из ящичка Я27". Вероятность повторного обращения к такому объекту в течении ближайших суток часто стремится к нулю. Зачем в таком случае тратить ресурсы на хранение этого объектв в памяти.

Модель объектов интенсивно используется в Ява-серверах, но как упоминал AVK, один из наиболее серьёзных недостатков у них — тормознутость. MS пропагандирует больше stateless модель, которая лично мне импонирует больше. Тем не менее кеширование нужно и оно действительно может очень здорово повысить производительность системы. Но подходить к этому нужно аккуратно, т.к. может получиться совершенно обратный результат.

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

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

MF>Но ведь объекты существительные так же нужны? Или по Вашему мнению от них можно отказаться?
По моему мнению — нет

Я мечтаю о системе, которая будет работать с entity-объектами без страшных performance penalty.
Но в существующей реальности IT прав. Либо stateful, либо перформанс...

... << RSDN@Home 1.0 beta 6 >>

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

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

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

Т.е. это понятие должно быть конфигурируемым??? Разрабочик бизнес компоненты должен будет зарегистрировать все объекты и указать системе какой у них жизненный цикл? Так я понимаю? Или разработчик безнес объекта должен сам реализовывать жизенный цикл его объектов.
Если первый вариант то мне видится только один вариант реализации сервер приложений должен выставлять фасадные заглушки с которыми работает пользователь (бизнес-программист прикладник) а уж вызовы методов этих заглушек интерпретировать в зависимости от зарегестрированного состояния объекта. Толи из кеша подымать, толи из базы стейтлесс объет загрузить выполнить и удалить??? Так? Я понимаю

... << RSDN@Home 1.0 beta 6a >>

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

MF>Но ведь объекты существительные так же нужны? Или по Вашему мнению от них можно отказаться?

Эту функциональность можно эмулировать.

Можно поступить следующим образом:

1. При запросе клиентом объект сериализуется и отдаётся ему полностью или частично (в случае сложных объектов). Далее клиент работает с этим объектом независимо и самостоятельно решает как долго ему жить. Т.е. кеширование осуществляет клиент. При этом под клиентом нужно понимать не только клиентскую машину, но и любую часть системы, выступающую в роли потребителя данных.

2. Обычно первый запрос объекта делается по его читабельному номеру (например, номер счёта). После того как объект считан и передан клиенту, клиент использует для обращения ID объекта в базе данных. Если такое обращение (по ID) имеет место быть, то такой объект можно положить и в кеш, т.к. вероятность третьего обращения к данному объекту весьма высока.

А как быть с синхронизацией доступа к кешу и с синхронизацией объекта в кеше и БД?

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

MF>Во!!! А я то думаю что еще впихнуть в сервер Статистику!!! Вот это та еще задача. Спасибо Вам большое много уважаемый IT!!!

Впихивать её не надо. В Windows есть классный механизм каунтеров, а в .NET поддержка этого дела. Разрабатывешь свой набор счётчиков и тебе уже сразу доступен мониторинг в лучшем виде. К тому же, так как это стандартная фича операционки, то вполне возможна обработка данной информации сторонными продуктами.

ЗЫ. Давай на ты, а то я как-то того...

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

Вот это я рекомендую всем Application Architecture for .NET: Designing Applications and Services.

MF>СтайтЛесс — это ведь объекты не хранящие своего состояния так? Т.е. те которые загружаются каждый раз из базы если с ним необходиом сделать какое либо действие, и уничтожающиеся после окончания этого действия? Так я понимаю? Т.е. основная нагрузка ложится на канал между АППСеврером и SQL сервером? Если у меня большое количество клиентов будет работать с этими объектами? то как же тогда выполнять кеширование??? И не будет ли узким местом слишком частые запросы к SQL серверу?

Индивидуальный подход к каждому типу объектов. Например справочник проводок я бы закачивал не раздумывая при старте сервера и больше о нём не думал.

MF>"Разработка масштабируемых приложений для Windows." Мастер-класс
MF>Дайте рецензию плиз.

Не читал

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

DMV>А как быть с синхронизацией доступа к кешу и с синхронизацией объекта в кеше и БД?

Хреново. Особенно если дело обстоит в распределённой среде. Приходится слать уведомления о том что объект expired.

IT>Хреново. Особенно если дело обстоит в распределённой среде. Приходится слать уведомления о том что объект expired.
Тут вообще много о кеше говорилось.
На мой взгляд — это очень сложная проблема.
Тем более что в .NET, насколько я знаю, нет особой поддержки (ASP.NET caching невсчет).
Нужна ли она вообще, за исключением тех мест, где требуется часто читать, но не обновлять (как план счетов например)?

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

DMV>На мой взгляд — это очень сложная проблема.

На мой тоже

DMV>Тем более что в .NET, насколько я знаю, нет особой поддержки (ASP.NET caching невсчет).

Нет, но я бы не отказался.

DMV>Нужна ли она вообще, за исключением тех мест, где требуется часто читать, но не обновлять (как план счетов например)?

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

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

ГВ>>Может оказаться, что и свой собственный придётся делать. Здесь нужно будет определиться — будет клиент обращаться к конкретным методам прикладных объектов (т.е. — будет он так или иначе, но зависимым от приложения) или будет взаимодействовать с сервером по какому-то своему протоколу, независимому от прикладной конфигурации. Второй вариант привлекательнее, но и сложнее.
MF>А бывают не свои собственные???? Я чето не понимаю? Хотя да

Бывают — IE — это не мой собственный, согласен

Но! Это он будет последний для кого я буду писать

) Так вот мне кажется — хотя и ошибаюсь

Ну да, сорвалОсь. Просто я привык "клиентом" называть именно тонкого клиента.

MF>
MF>>>То что придется объекты отражать на плоские таблицы я думал, и даже как то пытался продумать как это сделать. Если укажите книги где можно почитать об этом — то тоже великое Вам спасибо. Особенно об OO<->Relational маппинге

MF>>> это всетаки мой первый проект [...] Возмжно какая либо поэтапная работа?
ГВ>>Тяжеловатый он для первого проекта, тут я с остальными участниками соглашусь.

MF>Все что легче этого я уже съел

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

Согласен 100%.

ГВ>>А с поэтапностью легче определяться, когда более или менее ясно прописал всё (или почти всё) на бумаге. Кстати, да — схему (в смысле — алгоритмы для людей и компьютера) деплоймента нужно продумывать тоже сразу.
MF>Ага, я для этого дела даже книжку купил Крейга Лармана. UML и шаблоны проектирования. Но как то невлезает она в мою хохляцкую голову без практики, а практикой заняться не могу, нет учителя которому можно дать на проверку задание

Жизнь — лучший учитель. (псхпп IT)

MF>Если честно, то хочу завязаться с SECURITY по самые помидоры, но переживаю как бы не загубило оно мне проект, по скоростным показателям. А какой компромис выбрать -незнаю, ибо не знаю механизмов реализации различных спобов обсуждавшихся ранее. Одно точно, не хочу делать это средствами SQL

вернее полностью (частично все таки придется)

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

AVK>>>>Посмотри описание EJB — идея то она везде общая. А планировать жизненные циклы нужно обязательно, это одна из основных характеристик сервера приложений.
MF>>>Думаю, когда я напишу низкоуровневое ядро я вплотную займусь проектированиме объектов бизнеслогики, вот тогда и буду планировать жизденные циклы объектов.

ГВ>>НИ В КОЕМ СЛУЧАЕ ТАК НЕ ДЕЛАЙ! Модель жизненного цикла объекта разрабатывается изначально — это почти что альфа и омега! То есть, сначала ты должен определить возможные виды жизненных циклов объектов (аналогично, скажем, STATEFUL и STATELESS), потом — реализовать необходимую их поддержку в ядре, а только потом, исходя из их возможных комбинаций — проектировать реализацию бизнес-логики. Только не наоборот.
MF>Да??? А как я буду определять модель жизненного цикла объекта "шестеренка" если на первом этапе я не собираюсь приступать к реализации бизнес логики, а хочу все силы кинуть на формирование ядра???

Хорошо, переформулирую. Сначала определи возможные типы жизненных циклов. А жизненный цикл шестерёнки, конечно, будет определяться соответствующими... ну, петерёнками.

ГВ>>Под моделью ЖЦ я понимаю здесь summary ответов на примерно следующие вопросы:

ГВ>>- Что представляет из себя бизнес-объект? Каковы вариации типов бизнес-объектов?
MF>Очень абстрактный вопрос — очень тяжелоно на него ответить, очитвая что бизнес объектов на предприятии среднего уровня около 1000 и более

Если хорошо поискать конечно.

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

ГВ>>- Возможно ли их совмещение через наследование, агрегацию? Если да, то как?
MF>Думаю возможно, один из аргументов по которым хочу писать свою систему — это возможность управления наследованием и агрегацией (я лично очень сомневаюсь что в 8 такая фича будет)

Ну, управлять наследованем, наверное, лучше не надо. Его всё-таки проектировать имеет смысл,

как и агрегации. Вопрос в том — что куда можно агрегировать и что от чего наследовать.

ГВ>>- Чем и при каких условиях создаются объекты в памяти? Как отслеживаются?
MF>Вот этот вопрос я обдумывал, для каждой категории бизнесобъектов будет своеобразный "менеджер" который будет заниматся их созданием уничтожением, и наверное и маппингом, и даже кешированием.

Можно, конечно и в менеджер эту функциональность вынести...

ГВ>>- Чем и когда они удаляются из памяти? Из базы данных?
ГВ>>- Что происходит с объектами при транзакциях?
MF>Скорее всего как уже предлагалось ранее будет какая нибудь сериализация при транзакциях с контролем safepoint-ов.

Ой, не поможет тебе тут сериализация, ой не поможет... только всё запутает ещё больше... А про safepoint-ы -в правильном направлении идёте, товарищ.

ГВ>>Одна из задач, которую нужно будет решить — как обеспечить отсутствие конфликтов объектов разных версий. От неё потянутся "хвосты" на мэппинг. Другая задача — перезагрузка объектов "на лету" (понадобится для случая сервера, работающего в режиме 24x7).
MF>Да я уже думал что будет два типа объектов поддерживающих хотсвап и неподдерживающих. Т.е. если объект поддерживает хотсвап то сервис обновелния загружает его в систему сразу после прекращения использования всех его экзепляров. Если не поддерживает, производится перезагрузка сервера, холодный старт, пересборка или еще чего либо там.

Нет, не совсем так. Перезагружаемая единица здесь — группа классов (вырожденный случай — один класс). И учти, что они могут быть распределны по нескольким deployment-unit-ам (.DLL или что там будет). Привязкой к одному только объекту/классу здесь ничего не решишь.

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

IT>Ещё можно свою операционку написать, тоже будет очень привлекательно

Скажу больше — никто не мешает и свой компьютер под это дело слабать. Тоже дело нехитрое, вобщем-то.

Дальше я оставил только моменты, представляющиеся мне спорными... по ряду причин.

ГВ>>По возможности, его надо проработать хотя бы в общих чертах — как переносятся соединения с пользователем, как передаются сотояния объектов между серверами кластера, как выполняется синхронизация кэша, как управлять блокировками. Кстати, распределения нагрузки ты не увидишь (сможешь только предполагать что-то), пока не попытаешься её реально распределить по нескольким физическим серверам.

IT>На этих задачах можно состариться и так и не увидеть своё детище в производстве.

Это — едва ли.

Хотя, смотря что считать старостью

IT>Железный, проверенный способ поддержки распределённой нагрузки — stateless модель для объектов хранимых в базе данных. Stateful только для очень редкоизменяемых объектов.

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

ГВ>>Одна из задач, которую нужно будет решить — как обеспечить отсутствие конфликтов объектов разных версий. От неё потянутся "хвосты" на мэппинг. Другая задача — перезагрузка объектов "на лету" (понадобится для случая сервера, работающего в режиме 24x7).

IT>stateless, только stateless.

Не только...

ГВ>>Если немного обобщить, то относись к SQL-серверу (любому), как не более чем к средству хранения данных. Сразу снимется часть проблем с поиском оптимального решения с точки зрения MS-SQL и твоего ядра. Кстати, в перспективе, сможешь использовать и MTS.

IT>Мда, советик ещё тот

IT>SQL сервер — сердце системы и к нему нужно относится бережно и трепетно, лелеять и холить.

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

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

Да, только вся проблема — в согласовании этого слоя с остальными и в уменьшении возни с ним.

PS. Со всем остальным — согласен.

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Кстати, в литературе ты встретишь разные термины для обозначения одних и тех же вещей. Например, stateless подобен transitive в терминологии Шлеера, а stateful — persistable (аналогично).

Последнее не совсем верно. persistable = entity, stateful это более общий термин.

ГВ>Чаще всего для этого пользуются пулом (набором) ранее созданных объектов

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

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

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

IT>>SQL сервер — сердце системы и к нему нужно относится бережно и трепетно, лелеять и холить.

ГВ>Далеко не бесспорное высказывание. Всё зависит от того, каким образом ты хочешь дизайнить систему — как объектную, как объектно-реляционную (фактически — квазиобъектную), или как... реляционно-объектную (фактически — эклектичную).

Я хочу её дизайнить как максимально производительную.

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

ГВ>Да, только вся проблема — в согласовании этого слоя с остальными и в уменьшении возни с ним.

Именно поэтому и нужно иметь этот слой отдельным, что бы было меньше с ним возни

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

IT>На этих задачах можно состариться и так и не увидеть своё детище в производстве. Железный, проверенный способ поддержки распределённой нагрузки — stateless модель для объектов хранимых в базе данных. Stateful только для очень редкоизменяемых объектов.

Если ты внимательно читал — человек хочет энтити, т.е. стейтлесс модель идет лесом.

IT>Так же обрати внимание на частоту использования объектов и стоит ли их вообще держать в памяти или кешировать. Может получиться так что твоя память или кеш будет забита объектами, которые долгое время никому не нужны и смысла в применении подобных вещей нет.

Я в свое время делал это примерно так — была очередь обычных ссылок, при каждом запросе ссылка перемещалась в начало. Ссылки, вылезшие из очереди цеплялись через слабые ссылки. Точнее кеш был весь на слабых ссылках, а очередь служила как бы фиксатором часто запрашиваемых сущностей.

IT>stateless, только stateless.

Resin как то умудряется перегружать даже stateful, иногда даже после этого нет глюков.

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

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

DMV>Тем более что в .NET, насколько я знаю, нет особой поддержки (ASP.NET caching невсчет).

Там есть замечательная штука под названием WeakReference. Хотя конечно проблему синхронизации кешей в кластере это не решит.

... << RSDN@Home 1.0 beta 6 (np: тихо) >>

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

AVK>Если ты внимательно читал — человек хочет энтити, т.е. стейтлесс модель идет лесом.

Он хотел и VC++, но теперь он уже тоже идёт лесом

AVK>Я в свое время делал это примерно так — была очередь обычных ссылок, при каждом запросе ссылка перемещалась в начало. Ссылки, вылезшие из очереди цеплялись через слабые ссылки.

А для поиска ещё один сортированный список объектов?

IT>>stateless, только stateless.

AVK>Resin как то умудряется перегружать даже stateful, иногда даже после этого нет глюков.

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

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

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

Какие здесь могут быть проблемы. Нравится C# — пиши на нем, нет — тогда VB7, все равно все скомпилится в MSIL, вообще-то даже на нем можно писать.

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

Наваять "абы было" можно на любом языке. Сложность языка не дает никаких гарантий серъезности написанных на нем продуктов. Я правильно понял?

K>>Хоть один вразумительный довод. Но, имхо, ваше мнение ошибочно, как раз все наоборот.

MF> У меня этих мнений как грязи. Какое из них ошибочно? И что наоборот?

... << RSDN@Home 1.0 beta 3 >>

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

AVK>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Кстати, в литературе ты встретишь разные термины для обозначения одних и тех же вещей. Например, stateless подобен transitive в терминологии Шлеера, а stateful — persistable (аналогично).

AVK>Последнее не совсем верно. persistable = entity, stateful это более общий термин.

Да, пожалуй, что так ближе.

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

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

AVK>>Если ты внимательно читал — человек хочет энтити, т.е. стейтлесс модель идет лесом.

IT>Он хотел и VC++, но теперь он уже тоже идёт лесом

Не совсем верное утверждение — лесом пока ничего не идет. Просто, я дабы убрать излишниие недопонимания слегка перефразировал вопрос. Так как основное для меня осознать технологию и методы конструирования. А уже о языке я подумаю чуть позже — когда буду обладать более полной информацией о их возможностях и ограничениях.

Кстати по джаве — как то вскользь мимо меня проходило — что на джаве очень плохо с интерфейсной частью

— а для меня это один из важных аспектов при разработке клиентских приложений.

... << RSDN@Home 1.0 beta 6a >>

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

GS>Здравствуйте, Аноним, Вы писали:

А>>все же советую дождаться 8-ки (пара месяцев осталась). прикидочно — по мощности (пограммной платформы) сродни платформам типа Scala, Axapta. по цене не знаю. думаю, что проблем с нелицензионкой + документацией в РФ не будет

GS>Слушай, Аноним, а ты Сереге Кравченко передать привет можешь?

не. мимо. не знаю этого господина

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

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

MF>>Если честно, то хочу завязаться с SECURITY по самые помидоры, но переживаю как бы не загубило оно мне проект, по скоростным показателям. А какой компромис выбрать -незнаю, ибо не знаю механизмов реализации различных спобов обсуждавшихся ранее. Одно точно, не хочу делать это средствами SQL

вернее полностью (частично все таки придется)
ГВ>На самом деле, лучше полностью избавиться от необходимости работы с SQL-сервером
Да

, но как тогда например выбирать перечень объектов видимых клиенту? Неужели, допустим, грузить таблицу о ~1 000 000 записей а потом выбирать какие объекты показать клиенту а какие нет (при том что их может оказаться около 10-20). На мой взгляд — менеджер секюрити формирует критерии выборки объектов из базы на основании данных о правах пользователя, выполняющего конкретный запрос. А уж потом выполняется запрос с использованием этих критериев для уменьшения результатов выборки.

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

ГВ>>>- Возможно ли их совмещение через наследование, агрегацию? Если да, то как?
MF>>Думаю возможно, один из аргументов по которым хочу писать свою систему — это возможность управления наследованием и агрегацией (я лично очень сомневаюсь что в 8 такая фича будет)

ГВ>Ну, управлять наследованем, наверное, лучше не надо. Его всё-таки проектировать имеет смысл,

как и агрегации. Вопрос в том — что куда можно агрегировать и что от чего наследовать.
Именно это я и имел ввиду. Слабовато у меня еще с терминологией

Поэтому приходится по нескольку раз объяснять свои мысли

.

ГВ>>>Одна из задач, которую нужно будет решить — как обеспечить отсутствие конфликтов объектов разных версий. От неё потянутся "хвосты" на мэппинг. Другая задача — перезагрузка объектов "на лету" (понадобится для случая сервера, работающего в режиме 24x7).
MF>>Да я уже думал что будет два типа объектов поддерживающих хотсвап и неподдерживающих. Т.е. если объект поддерживает хотсвап то сервис обновелния загружает его в систему сразу после прекращения использования всех его экзепляров. Если не поддерживает, производится перезагрузка сервера, холодный старт, пересборка или еще чего либо там.

ГВ>Нет, не совсем так. Перезагружаемая единица здесь — группа классов (вырожденный случай — один класс). И учти, что они могут быть распределны по нескольким deployment-unit-ам (.DLL или что там будет). Привязкой к одному только объекту/классу здесь ничего не решишь.
Согласен

... << RSDN@Home 1.0 beta 6a >>

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

IT>>>SQL сервер — сердце системы и к нему нужно относится бережно и трепетно, лелеять и холить.

ГВ>>Далеко не бесспорное высказывание. Всё зависит от того, каким образом ты хочешь дизайнить систему — как объектную, как объектно-реляционную (фактически — квазиобъектную), или как... реляционно-объектную (фактически — эклектичную).

IT>Я хочу её дизайнить как максимально производительную.

А я — как максимально удобную для дизайна и дальнейшего развития. И одновременно — как максимально производительную.

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

ГВ>>Да, только вся проблема — в согласовании этого слоя с остальными и в уменьшении возни с ним.

IT>Именно поэтому и нужно иметь этот слой отдельным, что бы было меньше с ним возни

Вопрос в структуре этого слоя, только и всего.

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

AVK>>Я в свое время делал это примерно так — была очередь обычных ссылок, при каждом запросе ссылка перемещалась в начало. Ссылки, вылезшие из очереди цеплялись через слабые ссылки.

IT>А для поиска ещё один сортированный список объектов?

Зачем? Поиск по базе.

IT>Самое интересное, что из стейтлес можно всегда легко сделать стейтфул, а вот обратное неверно.

Вот о том и речь.

... << RSDN@Home 1.0 beta 6a (developer build)>>

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

MF>Кстати по джаве — как то вскользь мимо меня проходило — что на джаве очень плохо с интерфейсной частью

— а для меня это один из важных аспектов при разработке клиентских приложений.

Не то чтобы совсем плохо, просто довольно медленно. Хотя есть еще вариант использования eclipse. Там скорость уже приемлемая.

... << RSDN@Home 1.0 beta 6a (developer build)>>

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

ГВ>>На самом деле, лучше полностью избавиться от необходимости работы с SQL-сервером
MF>Да

, но как тогда например выбирать перечень объектов видимых клиенту? Неужели, допустим, грузить таблицу о ~1 000 000 записей а потом выбирать какие объекты показать клиенту а какие нет (при том что их может оказаться около 10-20). На мой взгляд — менеджер секюрити формирует критерии выборки объектов из базы на основании данных о правах пользователя, выполняющего конкретный запрос(Выделено мной — ГВ.). А уж потом выполняется запрос с использованием этих критериев для уменьшения результатов выборки.

MF>Хотя если использовать промежуточные слои для "маскировки" механизмов работы с базами данных такой подход наверняка будет неприменим.

Угу, в правильном направлении мыслишь. Когда я говорил о необходимости избавиться от работы с SQL-сервером, я отнюдь не имел ввиду перенос всей работы по выбору/сортировке и т.п. в память App-сервера. Здесь основная проблема — откуда идут основные ограничения проектирования. Если от SQL-сервера — то это весьма плохо, поскольку с одной стороны — на нём (MS-SQL) свет клином не сошёлся и есть другие серверы, а с другой — перемешается объектная и "реляционная" идеологии, а это уже дело — швах. Ну, то есть не полный швах пока,

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

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

MF>>>Если честно, то хочу завязаться с SECURITY по самые помидоры, но переживаю как бы не загубило оно мне проект, по скоростным показателям. А какой компромис выбрать — не знаю, ибо не знаю механизмов реализации различных спобов обсуждавшихся ранее. Одно точно, не хочу делать это средствами SQL

вернее полностью (частично все таки придется)

Генерить запросы к БД на основе метаданных.

ГВ>>На самом деле, лучше полностью избавиться от необходимости работы с SQL-сервером

Наверное, имел ввиду: не делать разграничения доступа средствами БД.

MF>Да

, но как тогда например выбирать перечень объектов видимых клиенту?

На основе его метаданных формировать предикат.

MF>Неужели, допустим, грузить таблицу о ~1 000 000 записей а потом выбирать какие объекты показать клиенту а какие нет (при том что их может оказаться около 10-20). На мой взгляд — менеджер секюрити формирует критерии выборки объектов из базы на основании данных о правах пользователя, выполняющего конкретный запрос. А уж потом выполняется запрос с использованием этих критериев для уменьшения результатов выборки.

MF>Хотя если использовать промежуточные слои для "маскировки" механизмов работы с базами данных такой подход наверняка будет неприменим.

... << RSDN@Home 1.0 beta 3 >>

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

AVK>>>>>10) Алгоритмы кеширования.
AVK>>>Без этого производительность твоего сервера будет плачевной. А если еще и OO-Relational меппинг наличествует, то производительность без кеша объектов будет просто никакая.
MF>>кеширование? — это ведь использование памяти? или например использование временных таблиц где хранятся уменьшенные выборки для работы с объектами? Все таким мне будет проще об этом думать когда я буду знать как работает мой сервер и что представляют из себя его объекты.

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

Только вот как явно задекларировать эти случаи. Имхо, подходит только для метаданных, для реальных бизнес объектов очень тяжело поддерживать кэш. А если будет несколько серверов приложений, и не как элементы кластера, а как полноценные сервера (допустим на каждую географическую точку по серверу), то, что, при изменении кэшируемого объекта в одном — оповещать другие?

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

А одним селектом для всей группы обойтись нельзя? И притом insert/update в пакетном режиме невозможен, все равно каждый раз процедуру вызывать придется.

ГВ>Производительность усвистит вниз до непотребных величин. Поэтому нужно продумать схему кэширования. Возможно — предварительное чтение объектов, возможно — групповое чтение обрабатываемого набора и такая же групповая запись. Можно найти другие варианты.

ГВ>Кстати, ты прав тоже — это действительно использование памяти.

... << RSDN@Home 1.0 beta 3 >>

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

IT>Я пока обхожусь там где надо доморощенными средствами, но пока у меня таких место не много это не проблема. А вообще хорошую систему кеширования можно сделать как отдельный компонент даже и вне привязки к апп-серверу, да только вот как всегда времени не хватает

Тогда и начать не с сервера приложений, а независимой компоненты кэша БД<->OO со своими правилами, зависимостями и т.д.

... << RSDN@Home 1.0 beta 3 >>

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

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

MF>>>>Если честно, то хочу завязаться с SECURITY по самые помидоры, но переживаю как бы не загубило оно мне проект, по скоростным показателям. А какой компромис выбрать — не знаю, ибо не знаю механизмов реализации различных спобов обсуждавшихся ранее. Одно точно, не хочу делать это средствами SQL

вернее полностью (частично все таки придется)

K>Генерить запросы к БД на основе метаданных.

ГВ>>>На самом деле, лучше полностью избавиться от необходимости работы с SQL-сервером

K>Наверное, имел ввиду: не делать разграничения доступа средствами БД.

MF>>Да

, но как тогда например выбирать перечень объектов видимых клиенту?

K>На основе его метаданных формировать предикат.

Я конечно дико извиняюсь за свою необразованность — но что такое предикат? Особенно в контексте заданного мною вопроса, объясните пожалуйста елси Вас не затруднит

... << RSDN@Home 1.0 beta 6a >>

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

K>>На основе его метаданных формировать предикат.

MF>Я конечно дико извиняюсь за свою необразованность — но что такое предикат? Особенно в контексте заданного мною вопроса, объясните пожалуйста елси Вас не затруднит

Обычный блок WHERE.
По научному:
ПРЕДИКАТ (от лат. praedicatum сказуемое), в узком смысле то же, что свойство; в широком смысле отношение, т. е. свойство нескольких предметов. В логике пропозициональная функция, т. е. выражение с неопределенными терминами (переменными), при выборе конкретных значений для этих терминов преобразующееся в осмысленное (истинное или ложное) высказывание.

... << RSDN@Home 1.0 beta 3 >>

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

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

K>>>На основе его метаданных формировать предикат.

MF>>Я конечно дико извиняюсь за свою необразованность — но что такое предикат? Особенно в контексте заданного мною вопроса, объясните пожалуйста елси Вас не затруднит

K>Обычный блок WHERE.
K>По научному:
K>ПРЕДИКАТ (от лат. praedicatum сказуемое), в узком смысле то же, что свойство; в широком смысле отношение, т. е. свойство нескольких предметов. В логике пропозициональная функция, т. е. выражение с неопределенными терминами (переменными), при выборе конкретных значений для этих терминов преобразующееся в осмысленное (истинное или ложное) высказывание.
А можно еще и с примером "на пальцах" — относительно формирования предиката для конкретного пользователя. Общий смысл слова я понял — уложить в голове относительно задачи секюрити — немогу

... << RSDN@Home 1.0 beta 6a >>

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

MF>А можно еще и с примером "на пальцах" — относительно формирования предиката для конкретного пользователя. Общий смысл слова я понял — уложить в голове относительно задачи секюрити — немогу

В простом виде абстрагируясь от механизмов авторизации с использованием ролей будет примерно так (хотя все зависит от твоей политики безопасности):
Задача: сотрудник хочет просмотреть журнал счет-фактур.
Ограничения на просмотр (описаны в его метаданных или в роли, в которую он входит):
1. Он имеет доступ на счета только с определенным статусом.
2. .. входящие в его подразделение и дочерние ему.
3. .. исходящие только из его подразделения.
4. и т.д.
На основе этих метаданных и можно сгнерить запрос к БД.

... << RSDN@Home 1.0 beta 3 >>

K>Тогда и начать не с сервера приложений, а независимой компоненты кэша БД<->OO со своими правилами, зависимостями и т.д.
Да вот по-моему не надо вообще этого кеша.
Get in — get out, и все.
Сильно сомневаюсь, что этот кеш на масштабируемости хорошо скажется.

K>Только вот как явно задекларировать эти случаи. Имхо, подходит только для метаданных, для реальных бизнес объектов очень тяжело поддерживать кэш. А если будет несколько серверов приложений, и не как элементы кластера, а как полноценные сервера (допустим на каждую географическую точку по серверу), то, что, при изменении кэшируемого объекта в одном — оповещать другие?

Согласен, создание своего кеша — занятие трудное и бессмысленное.
Во всяком случае в MS COM+ предлагается делать все stateless.

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

K>>Тогда и начать не с сервера приложений, а независимой компоненты кэша БД<->OO со своими правилами, зависимостями и т.д.
DMV>Да вот по-моему не надо вообще этого кеша.
DMV>Get in — get out, и все.
DMV>Сильно сомневаюсь, что этот кеш на масштабируемости хорошо скажется.

Для метаданных — он самый раз подходит, проверено. Ну еще некоторые вещи я кэширую на клиенте.

... << RSDN@Home 1.0 beta 3 >>

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

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

MF>>А можно еще и с примером "на пальцах" — относительно формирования предиката для конкретного пользователя. Общий смысл слова я понял — уложить в голове относительно задачи секюрити — немогу

K>В простом виде абстрагируясь от механизмов авторизации с использованием ролей будет примерно так (хотя все зависит от твоей политики безопасности):
K>Задача: сотрудник хочет просмотреть журнал счет-фактур.
K>Ограничения на просмотр (описаны в его метаданных или в роли, в которую он входит):
K>1. Он имеет доступ на счета только с определенным статусом.
K>2. .. входящие в его подразделение и дочерние ему.
K>3. .. исходящие только из его подразделения.
K>4. и т.д.
K>На основе этих метаданных и можно сгнерить запрос к БД.
Аааа! ну если это и есть предикат, то я именно об этом и думал.

... << RSDN@Home 1.0 beta 6a >>

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

IT>>Я хочу её дизайнить как максимально производительную.

ГВ>А я — как максимально удобную для дизайна и дальнейшего развития. И одновременно — как максимально производительную.

Я слабо верю в одновременность удобной объектной модели и производительности

Давай попробуем на живом примере. Есть вот такая страница http://www.rsdn.ru/forum/main.aspx. Все данные на ней запрашиваются в реальном времени.

Есть две таблицы, одна содержит описание формов, другая список сообщений. Связь между ними: каждая запись таблицы сообщений имеет id форума, к которому она принадлежит.

Вопрос, какой должна быть модель объектов и как она будет запрашивать данные из базы, чтобы это было максимально удобно и эффективно?

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

IT>Вопрос, какой должна быть модель объектов и как она будет запрашивать
IT>данные из базы, чтобы это было максимально удобно и эффективно?

Извиняюсь, что вмешиваюсь.
ИМХО объектная модель должна быть удобной для программера.
Запрашиваться данные из БД будут через некоторый класс служебных объектов
и(или) хранимых процедур, позволяющих нам изолировать объекты сервера от
структуры БД. Во время разработки можно будет реализовать все элементарными
запросами — главное, чтобы быстрее сдвинуться с места. Когда (если(а это без
сомнения произойдет)) изделие начнет тормозить преобразуем объекты и(или)
процедуры доступа к БД (наймем крутого запросописателя или обратимся в форумы
RSDN

), а может даже введем дополнительные таблицы с некоторой
избыточной информацией.

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

МС>ИМХО объектная модель должна быть удобной для программера.

Несомненно.

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

А где объектная модель? Покажите мне объектную модель.

МС>Когда (если(а это без сомнения произойдет)) изделие начнет тормозить преобразуем объекты и(или) процедуры доступа к БД (наймем крутого запросописателя или обратимся в форумы RSDN

), а может даже введем дополнительные таблицы с некоторой избыточной информацией.

Со 100% уверенностью могу сказать, что с таким подходом это начнёт тормозить только у заказчика, когда система будет под нагрузкой, не раньше.

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

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

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

IT>А где объектная модель? Покажите мне объектную модель.

не раздумывая долго об именах что-то вроде

class ForumsManager
{
 ...........
 ForumsInfo GetForumsInfo( LevelOfDetails, ... )
 (или)
 List(любой) GetForumsInfo( LevelOfDetails, ... )
 ...........
}
class ForumsInfo (отсутствует в случае если используется список)
{
   ForumInfoData[]
}
class ForumInfoData
{
  // поля, которые должны быть отображены
}

IT>Со 100% уверенностью могу сказать, что с таким подходом это
IT>начнёт тормозить только у заказчика, когда система будет под
IT>нагрузкой, не раньше.

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

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

IT>>А где объектная модель? Покажите мне объектную модель.

МС>не раздумывая долго об именах что-то вроде

Так что всё-таки лучше отдельные объекты или список?

IT>>Со 100% уверенностью могу сказать, что с таким подходом это начнёт тормозить только у заказчика, когда система будет под нагрузкой, не раньше.

МС>Да. Я больше писал о системе, которая всегда "под рукой", а не о платформе, на которой создаются решения для стороннего заказчика.

В этом случае такое допущение можно допустить

Но мы в этой теме вроде как обсуждаем универсальное решение на продажу

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

IT>Так что всё-таки лучше отдельные объекты или список?

В любом случае на каждый форум понадобится отдельный объект, содержащий информацию о нем.
Но это будет объект, который служит _только_ для передачи информации по форуму в рамках
запроса GetForumsInfoList и для него в базе нет соответствия 1:1. Он формируется из двух
таблиц (Forum(s) — Message(s)). Возможно, что где-то кэшируется (но только, если в этом
есть потребность).

IT>В этом случае такое допущение можно допустить

Но мы в этой теме вроде как обсуждаем
IT>универсальное решение на продажу

Да. Это я не по теме "вклинился".

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

МС>>не раздумывая долго об именах что-то вроде
IT>Так что всё-таки лучше отдельные объекты или список?

отдельные объекты всегда гибче чем коллекции, хотя бы
потому что коллекции вносят дополнительный уровень indirection-а, а
этот уровень (как все материальное) добавляет сложность.

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

IT>>Так что всё-таки лучше отдельные объекты или список?

МС>В любом случае на каждый форум понадобится отдельный объект, содержащий информацию о нем.
МС>Но это будет объект, который служит _только_ для передачи информации по форуму в рамках запроса GetForumsInfoList и для него в базе нет соответствия 1:1. Он формируется из двух таблиц (Forum(s) — Message(s)).

Т.е. это просто структурка?

МС>Возможно, что где-то кэшируется (но только, если в этом есть потребность).

Вот это тоже интересно, как организовать кешь в данном примере.

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

IT>Я слабо верю в одновременность удобной объектной модели и производительности

Идеалы — они только в снах встречаются

IT>Давай попробуем на живом примере. Есть вот такая страница http://www.rsdn.ru/forum/main.aspx. Все данные на ней запрашиваются в реальном времени.

IT>Есть две таблицы, одна содержит описание формов, другая список сообщений. Связь между ними: каждая запись таблицы сообщений имеет id форума, к которому она принадлежит.

Ну, скажем так — подобное описание к постановке задачи на объектное проектирование никакого отношения не имеет. Что это за "таблицы"? Знать не знаю такого зверя!

Есть классы, объекты и отношения объектов.

IT>Вопрос, какой должна быть модель объектов и как она будет запрашивать данные из базы, чтобы это было максимально удобно и эффективно?

Не максимально, но мне нравится:

Здесь я немного пофантазировал — предположил, что сообщение может быть одновременно началом нового топика в форуме и реплаем на другое сообщение. Ну, имею же право, в конце концов.

Значит так, кое-какие пояснения.
1. MessagePlacement связан как минимум с экземпляром одного из двух классов: Reply или TopicHeader.
2. Текст заголовка топика может отличаться от subject-а сообщения.
3. Структура БД и операций с ней выводится из этой схемы (информации для этого достаточно).
4. Во время эксплуатации App-сервер собирает статистику по работе с БД и по необходимости

выполняется её оптимизация (это — почти как как всегда) с донастройкой маппинга.
5. Да, чуть не забыл! все классы — persistable.

Вот так или примерно так.

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

K>Только вот как явно задекларировать эти случаи. Имхо, подходит только для метаданных, для реальных бизнес объектов очень тяжело поддерживать кэш.

Что ты имеешь ввиду под "задекларировать" и "поддерживать"?

K>А если будет несколько серверов приложений, и не как элементы кластера, а как полноценные сервера (допустим на каждую географическую точку по серверу), то, что,
при изменении кэшируемого объекта в одном — оповещать другие?

Можно и так, если очень хочется.

Хотя лучше, наверное, пользоваться репликацией.

K>А одним селектом для всей группы обойтись нельзя? И притом insert/update в пакетном режиме невозможен, все равно каждый раз процедуру вызывать придется.

Зато insert/update возможны в фоновом режиме.

K>Под пулом, наверное, подразумеваешь объекты не заполненные данными?

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

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

IT>Т.е. это просто структурка?

Да. Объектом я ее совершенно некорректно "обозвал". Погорячился.

IT>Вот это тоже интересно, как организовать кешь в данном примере.

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

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

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

K>>Только вот как явно задекларировать эти случаи. Имхо, подходит только для метаданных, для реальных бизнес объектов очень тяжело поддерживать кэш.

ГВ>Что ты имеешь ввиду под "задекларировать" и "поддерживать"?

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

K>>А если будет несколько серверов приложений, и не как элементы кластера, а как полноценные сервера (допустим на каждую географическую точку по серверу), то, что,
ГВ>при изменении кэшируемого объекта в одном — оповещать другие?

ГВ>Можно и так, если очень хочется.

Хотя лучше, наверное, пользоваться репликацией.

Я забыл сказать, что БД у них одна!!! Или такое не практикуется, с одной базой и несколько серверов приложений?
Представляю чем может закончиться такого рода оповещения, если серверов эдак 15.

K>>А одним селектом для всей группы обойтись нельзя? И притом insert/update в пакетном режиме невозможен, все равно каждый раз процедуру вызывать придется.

ГВ>Зато insert/update возможны в фоновом режиме.

Не вижу связи.

K>>Под пулом, наверное, подразумеваешь объекты не заполненные данными?

ГВ>Не совсем. Под пулом я подразумеваю наборы неиспользуемых объектов.

Тогда это кэш. Правильно понял?

... << RSDN@Home 1.0 beta 3 >>

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

K>Под первым: В настройках системы указывать о необходимости кэширования экземпляров конкретного типа или сервер со своим супер интелектуальным механизмом сам будет определять какие именно сущности надо кэшировать (причем тип безразличен, допустим все наследники от базового BusinessObject)?

Все так, только не в настройках системы, а в настройках конкретного приложения.

... << RSDN@Home 1.0 beta 6a (developer build)>>

ГВ>>Одна из задач, которую нужно будет решить — как обеспечить отсутствие конфликтов объектов разных версий. От неё потянутся "хвосты" на мэппинг. Другая задача — перезагрузка объектов "на лету" (понадобится для случая сервера, работающего в режиме 24x7).

IT>stateless, только stateless.

Вот тут много говорилось об объектных моделях.
А как народ относится к message-based системам?
Т.е. все взаимодействие происходит при помощи сообщений.
Но здесь сообщение — это не вызов метода объекта.
Это скорее некий документ определенной структуры.
И есть набор классов — менеджеров, которые знают, как обрабатываеть определенные типы сообщений.
Эти классы stateless.

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

DMV>А как народ относится к message-based системам?

Хорошо относится.

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

Как бы продолжая свою тему и пытаясь все-таки определится с вопросом "Начем и как писать трехзвенку" — хочу предложить Вам господа (особенно тем кто принимал самое активное участие в обсуждении — (псхпп IT, AndrewVK, ГВ) высказать свое мнение о статьях находящихся по адресу :
http://russian.joelonsoftware.com/index.html. Вернее не сколько о статьях, сколько о ваших утверждениях ранее высказанных в этом топике, и о том как они пересекаются с мнением автора статей.

А особенно о двух конкретных:
Первая возобновила во мне желание писать на С++ — http://russian.joelonsoftware.com/Articles/BacktoBasics.html
Вторая, добавляет надежд на то что то что я затеваю имеет реальный шанс на выживание — http://russian.joelonsoftware.com/Articles/FireAndMotion.html

ТОЛЬКО ПОЖАЛУЙСТА поймите меня правильно, я не хочу в обсуждении этого топика разжечь очередную "священную войну".

... << RSDN@Home 1.0 beta 6a >>

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

MF>http://russian.joelonsoftware.com/index.html. Вернее не сколько о статьях, сколько о ваших утверждениях ранее высказанных в этом топике, и о том как они пересекаются с мнением автора статей.

Полезное, и ИМХО, довольно здравое вИдение софтверной "индустрии" и человека в ней.

MF>А особенно о двух конкретных:
MF>Первая возобновила во мне желание писать на С++ — http://russian.joelonsoftware.com/Articles/BacktoBasics.html

Мне особенно понравилось вот это:

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

MF>Вторая, добавляет надежд на то что то что я затеваю имеет реальный шанс на выживание — http://russian.joelonsoftware.com/Articles/FireAndMotion.html

А здесь вот это:

Если вы не ведёте огонь, враг ведёт огонь по вам, вынуждая вас залечь.

И это:

Люди начинают волноваться по поводу .NET и решают полностью переделать архитектуру под .NET, потому что они думают, что они вынуждены это сделать. Microsoft ведёт по вам огонь, и это всего лишь огонь прикрытия(выделено мной — ГВ.) для того чтобы они могли двигаться вперёд, а вы нет.

И остальные рассуждения тоже неплОхи.

MF>ТОЛЬКО ПОЖАЛУЙСТА поймите меня правильно, я не хочу в обсуждении этого топика разжечь очередную "священную войну".

Да, её и не будет, не переживай.

Почитай ещё Программистский камень.

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

ГВ>Да, её и не будет, не переживай.

ГВ>Почитай ещё Программистский камень.
Да я ее еще год назад выкачал, но никак приступить немогу — нехватка времени

... << RSDN@Home 1.0 beta 6a >>

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

ГВ>>Что ты имеешь ввиду под "задекларировать" и "поддерживать"?

K>Под первым: В настройках системы указывать о необходимости кэширования экземпляров конкретного типа или сервер со своим супер интелектуальным механизмом сам будет определять какие именно сущности надо кэшировать (причем тип безразличен, допустим все наследники от базового BusinessObject)?

Угу, именно, что "или сервер...", поскольку по идее кэшировать нужно все persistable-сущности. А основная проблема — не что кэшировать, а как кэшировать.

Пользователь (администратор) должен только управлять параметрами кэширования. Конкретная структура параметров зависит от того, что именно можно регулировать в твоём кэше — min время удержания, объём кэша, max количество зарезервированных экземпляров одно типа и т.п. Исходная информация для администратора — статистика, собираемая App-сервером.

K>Под вторым проблема, описанная ниже.

K>>>А если будет несколько серверов приложений, и не как элементы кластера, а как полноценные сервера (допустим на каждую географическую точку по серверу), то, что,
ГВ>>при изменении кэшируемого объекта в одном — оповещать другие?

ГВ>>Можно и так, если очень хочется.

Хотя лучше, наверное, пользоваться репликацией.

K>Я забыл сказать, что БД у них одна!!! Или такое не практикуется, с одной базой и несколько серверов приложений?
K>Представляю чем может закончиться такого рода оповещения, если серверов эдак 15.

Такая организация нецелесообразна сама по себе. Данные могут быть в одной БД, но тогда удалённым пользователям не нужны App-серверы на их машинах, а нужны тонкие клиенты. Зачем становиться с ног на голову?

K>>>А одним селектом для всей группы обойтись нельзя? И притом insert/update в пакетном режиме невозможен, все равно каждый раз процедуру вызывать придется.

ГВ>>Зато insert/update возможны в фоновом режиме.

K>Не вижу связи.

Связь очень простая — по крайней мере update (при грамотном кешировании и синхронизации) может быть выполнен несколько раз в памяти ни разу не попав при этом в БД. Вернее — попадёт только результат последнего update. Такая схема накладывает, конечно, определённые требования, например, на питание узлов с App-серверами, но позволяет в некоторых случаях избежать проведения серии update-ов одних и тех же записей в БД. Точно также insert может быть "перехвачен" последующим delete-ом вовсе не достигнув при этом БД.

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

Хотя на самом деле в реальных условиях время, затрачиваемое на модификации БД существенно меньше всяческих select-ов.

K>>>Под пулом, наверное, подразумеваешь объекты не заполненные данными?

ГВ>>Не совсем. Под пулом я подразумеваю наборы неиспользуемых объектов.

K>Тогда это кэш. Правильно понял?

Нет, не совсем. Кэш (Cache) — это обобщённое название программного (в нашем случае) механизма, выполняющего буферизацию данных. Цель кэширования (и кэша) — снижние издержек на обращения к БД. Пул (Pool) — это один из способов организации хранения неиспользуемых, но уже сконструированных объектов (например, под которые уже выделена память операцией new). Очередь (Queue) — это способ упорядочения доступа в частности, к пулу объектов. Вот и всё. Смешивать понятия здесь не совсем правомерно.

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

ГВ>Угу, именно, что "или сервер...", поскольку по идее кэшировать нужно все persistable-сущности.

Тут идея простая

1) Stateless — пул
2) Stateful — не трогать
3) Entity — кеш с контролем уникальности

ГВ>Хотя на самом деле в реальных условиях время, затрачиваемое на модификации БД существенно меньше всяческих select-ов.

А если еще вспомнить что очень часто нужна еще связь по данным со старыми системами то получается что запись лучше не кешировать, а писать сразу. Единственное что здесь нужно — дать возможность групповых операций. Т.е. перед началом модификации вызываем BeginUpdate, все изменения фиксируются в контексте, но в базу не пишутся, а по EndUpdate они скопом сваливаются в базу. Но здесь уже нужна поддержка транзакций именно со стороны сервера приложений. Т.е. при изменении внутри группового апдейта какого либо объекта нужно его сериализовать в специальный лог, а при исключении все изменения откатывать.

... << RSDN@Home 1.0 beta 6a (developer build)>>

ГВ>>>Можно и так, если очень хочется.

Хотя лучше, наверное, пользоваться репликацией.

K>>Я забыл сказать, что БД у них одна!!! Или такое не практикуется, с одной базой и несколько серверов приложений?
K>>Представляю чем может закончиться такого рода оповещения, если серверов эдак 15.

ГВ>Такая организация нецелесообразна сама по себе. Данные могут быть в одной БД, но тогда удалённым пользователям не нужны App-серверы на их машинах, а нужны тонкие клиенты. Зачем становиться с ног на голову?

???
Ничего не понимаю.
Зачем вообще ПОЛЬЗОВАТЕЛЯМ НА ИХ МАШИНАХ App-сервера?
Разве кто-то предлагал такое?

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

ГВ>>>>Можно и так, если очень хочется.

Хотя лучше, наверное, пользоваться репликацией.

K>>>Я забыл сказать, что БД у них одна!!! Или такое не практикуется, с одной базой и несколько серверов приложений?
K>>>Представляю чем может закончиться такого рода оповещения, если серверов эдак 15.
ГВ>>Такая организация нецелесообразна сама по себе. Данные могут быть в одной БД, но тогда удалённым пользователям не нужны App-серверы на их машинах, а нужны тонкие клиенты. Зачем становиться с ног на голову?

DMV>???
DMV>Ничего не понимаю.
DMV>Зачем вообще ПОЛЬЗОВАТЕЛЯМ НА ИХ МАШИНАХ App-сервера?
DMV>Разве кто-то предлагал такое?

Kreek как раз и предлагал.

ИМХО, удалять App-сервер от БД имеет смысл только ради приближения его к пользователям, но приближать в этом случае нужно и базу данных тоже (см. ниже). А если не приближать ничего, то пользователям нужны тонкие клиенты.

А зачем держать 15 удалённых App-серверов, если узел с базой данных один?

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

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

AVK>Тут идея простая

AVK>1) Stateless — пул
AVK>2) Stateful — не трогать
AVK>3) Entity — кеш с контролем уникальности

Тоже вариант. Весь прикол как раз в организации кэширования Entity.

ГВ>>Хотя на самом деле в реальных условиях время, затрачиваемое на модификации БД существенно меньше всяческих select-ов.

AVK>А если еще вспомнить что очень часто нужна еще связь по данным со старыми системами то получается что запись лучше не кешировать, а писать сразу.

Вот уж что да, то есть! Особенно если нужно ещё обеспечить эксплуатацию старой системы одновременно с новой, то...

AVK>Единственное что здесь нужно — дать возможность групповых операций. Т.е. перед началом модификации вызываем BeginUpdate, все изменения фиксируются в контексте, но в базу не пишутся, а по EndUpdate они скопом сваливаются в базу. Но здесь уже нужна поддержка транзакций именно со стороны сервера приложений. Т.е. при изменении внутри группового апдейта какого либо объекта нужно его сериализовать в специальный лог, а при исключении все изменения откатывать.

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

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

ГВ>Тоже вариант. Весь прикол как раз в организации кэширования Entity.

Ну так о том и речь. Но если отказаться от постоянного кеширования по записи то проблем особых нет, а GC позволит кешу работать совместно с его механизмами.

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

Ну чаще всего в общем то все таки transaction log используют.

... << RSDN@Home 1.0 beta 6a (developer build)>>

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

MF>Первая возобновила во мне желание писать на С++ — http://russian.joelonsoftware.com/Articles/BacktoBasics.html

Как я понимаю, особенно возбуждающим тебе показался последний абзац.

Всё это вещи, которые заставляют думать о байтах, и они оказывают влияние на архитектурные и стратегические решения, которые мы принимаем. Я придерживаюсь мнения, что студенты, начинающие изучать программирование, должны начинать с начала, использовать C и подниматься вверх от процессора. Мне противно, как часто программа обучения строится на посылке, что Java представляет собой хороший язык для того, чтобы начинать программировать, потому что это так "просто" и не нужно отвлекаться на эти скучные детали про строки и выделение памяти, и сразу можно изучить кульные ООП-штучки которые помогут сделать ваши большие программы так восхитительно модульными. Это педагогический провал. Поколения выпускников снисходят на нас, раскидывая алгоритмы маляра Шлемиэля налево и направо, даже не понимая этого, поскольку у них нет представления о том, что строки на нижнем уровне сложны, даже если из их перлового скрипта этого не видно. Если хочешь научить кого-то хорошо, надо начинать с основ. Как в Karate Kid. Wax On, Wax Off. Wax On, Wax Off. Повторять три недели. После этого Снести Башню Другому Пацану несложно.

Всё правильно, целиком и полностью поддерживаю. Учить в институте надо C++ и байты, и становиться в этом гуру именно там. А на работе нужно применять Java, ну на худой конец .NET

, и выдавать на гора рабочий код.

MF>Вторая, добавляет надежд на то что то что я затеваю имеет реальный шанс на выживание — http://russian.joelonsoftware.com/Articles/FireAndMotion.html

Есть такое дело. У меня в конторе даже по серьёзному назревает шуточный проект, называемый "Interruption Management System"

MF>ТОЛЬКО ПОЖАЛУЙСТА поймите меня правильно, я не хочу в обсуждении этого топика разжечь очередную "священную войну".

Надо было написать "Не поймите меня правильно!"

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

ГВ>Мне особенно понравилось вот это:

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

Художественно

ГВ>А здесь вот это:

Если вы не ведёте огонь, враг ведёт огонь по вам, вынуждая вас залечь.

Жизненно

ГВ>И это:

Люди начинают волноваться по поводу .NET и решают полностью переделать архитектуру под .NET, потому что они думают, что они вынуждены это сделать. Microsoft ведёт по вам огонь, и это всего лишь огонь прикрытия(выделено мной — ГВ.) для того чтобы они могли двигаться вперёд, а вы нет.

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

BTW, на самом деле, действительно интересно, где он не сошёлся со своими менеджерами? Ведь как бы там абстрактно не говорили об MS, там всё же работают люди, которые собственно и принимают решения типа Сан козлы, Спольски свободен, .NETу быть.

ГВ>И остальные рассуждения тоже неплОхи.

Ну да, в том же ключе

MF>>ТОЛЬКО ПОЖАЛУЙСТА поймите меня правильно, я не хочу в обсуждении этого топика разжечь очередную "священную войну".

ГВ>Да, её и не будет, не переживай.

NO WAY

NEVER

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

ГВ>А основная проблема — не что кэшировать, а как кэшировать.

Очень верное замечание. Я бы ещё добавил — где кешировать.

ГВ>Пользователь (администратор) должен только управлять параметрами кэширования. Конкретная структура параметров зависит от того, что именно можно регулировать в твоём кэше — min время удержания, объём кэша, max количество зарезервированных экземпляров одно типа и т.п. Исходная информация для администратора — статистика, собираемая App-сервером.

Кроме развитых средств кешировния тут нужны ещё и развитые средства статистики, мониторинга и администрировния. И всё в одном флаконе.

ГВ>Такая организация нецелесообразна сама по себе. Данные могут быть в одной БД, но тогда удалённым пользователям не нужны App-серверы на их машинах, а нужны тонкие клиенты. Зачем становиться с ног на голову?

Правильно, давайте не будем о репликации, как об обслютном мировом зле

ГВ>Связь очень простая — по крайней мере update (при грамотном кешировании и синхронизации) может быть выполнен несколько раз в памяти ни разу не попав при этом в БД. Вернее — попадёт только результат последнего update. Такая схема накладывает, конечно, определённые требования, например, на питание узлов с App-серверами, но позволяет в некоторых случаях избежать проведения серии update-ов одних и тех же записей в БД. Точно также insert может быть "перехвачен" последующим delete-ом вовсе не достигнув при этом БД.

MS SQL Server team отдыхает. Нет ничего проще, чем написать свой апп-сервер, который как бык овцу покрывает все возможности любого SQL сервера

ГВ>Во-вторых, можно передать серверу группу заданий на обновление одним сеансом, что позволит сэкономить на некотором оверхэде, привносимым тем же ADO.

ГВ>Хотя на самом деле в реальных условиях время, затрачиваемое на модификации БД существенно меньше всяческих select-ов.

А вот это совершенно правильное утверждение.

ГВ>Нет, не совсем. Кэш (Cache) — это обобщённое название программного (в нашем случае) механизма, выполняющего буферизацию данных. Цель кэширования (и кэша) — снижние издержек на обращения к БД. Пул (Pool) — это один из способов организации хранения неиспользуемых, но уже сконструированных объектов (например, под которые уже выделена память операцией new). Очередь (Queue) — это способ упорядочения доступа в частности, к пулу объектов. Вот и всё. Смешивать понятия здесь не совсем правомерно.

Кеши бывают разные. Иногда диаметрально противоположные.

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

С другой стороны, MS SQL Server Team опять отдыхает, когда в дело вступает MSIE со своим кешем HTML страниц на клиенте. В данном случае данные уже не просто считаны из хранилища, но уже и преобразованы в потребный для клиента вид, считаны с сервера, распарсены и в любой момент готовы к потреблению.

Т.е. чем более кеш предполагает абстакцию, тем ближе он должен распологаться к хранилищу. Кеширование же уже ранее подготовленных данных, тем эффективнее, чем оно ближе к клиенту.

Истина, как обычно где-то... не то чтобы по середине, а скорее всего в разных, порой совершенно непредсказуемых местах

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

IT>Кроме развитых средств кешировния тут нужны ещё и развитые средства статистики, мониторинга и администрировния. И всё в одном флаконе.

Абсолютно верное замечание, именно поэтому, в частности, рискованно закладываться на механизмы сбора статистики, предусмотренные в той или ной базовой ОС.

ГВ>>Такая организация нецелесообразна сама по себе. Данные могут быть в одной БД, но тогда удалённым пользователям не нужны App-серверы на их машинах, а нужны тонкие клиенты. Зачем становиться с ног на голову?

IT>Правильно, давайте не будем о репликации, как об обслютном мировом зле

Кто говорил, что это АМЗ? Тело в студию!

IT>MS SQL Server team отдыхает. Нет ничего проще, чем написать свой апп-сервер, который как бык овцу покрывает все возможности любого SQL сервера

Небольшое замечание "по существу". Бык покрывает коров (иногда — священных), овец же покрывают бараны, а App-серверы так вообще бывают бывают разными.

IT, прости мне мою иронию.

IT>Т.е. чем более кеш предполагает абстакцию, тем ближе он должен распологаться к хранилищу. Кеширование же уже ранее подготовленных данных, тем эффективнее, чем оно ближе к клиенту.

Что значит "абстракция" и "подготовка данных"? Абстракция чего? Подготовка данных для чего?

IT>Истина, как обычно где-то... не то чтобы по середине, а скорее всего в разных, порой совершенно непредсказуемых местах

Вот уж, с чем согласен, так согласен.

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

IT>Да, чувствуется, что жизнь мужика потрепала и он поправу возглавляет колонну идущих на х.., простите, в даль, и орущих Микрасофт — масдай, при этом используя единственно доступный аргумент — спакуха, пацаны, я знаю, я там работал

Какой штиль!

А всего-то — человек посмел адекватно оценить действия MS.

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

ГВ>Какой штиль!

А всего-то — человек посмел адекватно оценить действия MS.

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

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

ГВ>>Какой штиль!

А всего-то — человек посмел адекватно оценить действия MS.

IT>Оценка обычно подразумевает аргументы, без аргументов это просто наезд. К тому же, ты видимо не читал его других статей, почитай, очень занимательно

Читал, понравилось.

В частности, в статье Fire & Motion, о которой мы говорим — ИМХО, очень здраво сказано, что MS ведёт "огонь прикрытия". А аргументы, так там с полстатьи — сплошняком аргументы "за". В том-то и дело, что он рассматривает как раз те самые микровзаимодйствия в коллективах, которыми можно объяснить "успех" той или иной технологии или смену стратегии компании. ИМХО — очень даже жизненные оценки поведения людей и побуждающих их на то причин.

А почему у тебя такая резко отрицательная оценка?

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

ГВ>А почему у тебя такая резко отрицательная оценка?

Не люблю необоснованных наездов, только и всего. Где-то у него есть статейка целиком и полностью этому посвящённая, тому что MS это мировое зло и не имеет права на существование. Хотя мужик, надо признать грамотный, но видимо на что-то обиженный.

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

ГВ>Ну, скажем так — подобное описание к постановке задачи на объектное проектирование никакого отношения не имеет.

Т.е. ты хочешь сказать, что объекты первичны, а задача которую они решают вторична

ГВ>Что это за "таблицы"? Знать не знаю такого зверя!

Есть классы, объекты и отношения объектов.

Есть задача, которую надо решить

ГВ>Здесь я немного пофантазировал — предположил, что сообщение может быть одновременно началом нового топика в форуме и реплаем на другое сообщение. Ну, имею же право, в конце концов.

Само собой

ГВ>1. MessagePlacement связан как минимум с экземпляром одного из двух классов: Reply или TopicHeader.

Ok.

ГВ>2. Текст заголовка топика может отличаться от subject-а сообщения.

Не вопрос.

ГВ>3. Структура БД и операций с ней выводится из этой схемы (информации для этого достаточно).

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

ГВ>4. Во время эксплуатации App-сервер собирает статистику по работе с БД и по необходимости

выполняется её оптимизация (это — почти как как всегда) с донастройкой маппинга.

Вот это самое интересное. Жуть как хочется посмотреть на реализацию.

ГВ>5. Да, чуть не забыл! все классы — persistable.

Тоже не вопрос.

ГВ>Вот так или примерно так.

Пока не понятно как, давай развивать мысль.

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

ГВ>>Ну, скажем так — подобное описание к постановке задачи на объектное проектирование никакого отношения не имеет.
IT>Т.е. ты хочешь сказать, что объекты первичны, а задача которую они решают вторична

Не-а

Я хочу сказать, что таблицы — это способ организации хранилища, а первична как раз таки задача — организация форумов.

ГВ>>Что это за "таблицы"? Знать не знаю такого зверя!

Есть классы, объекты и отношения объектов.

IT>Есть задача, которую надо решить

Истинно так, и к таблицам она до поры до времени не имеет никакого отношения.

ГВ>>Здесь я немного пофантазировал — предположил, что сообщение может быть одновременно началом нового топика в форуме и реплаем на другое сообщение. Ну, имею же право, в конце концов.

IT>Само собой

OK, принято.

ГВ>>1. MessagePlacement связан как минимум с экземпляром одного из двух классов: Reply или TopicHeader.
IT>Ok.

ГВ>>2. Текст заголовка топика может отличаться от subject-а сообщения.
IT>Не вопрос.
OK

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

А вот ничего подобного — структуру БД будем определять после объектной декомпозиции. Повторяю — сначала объектная декомпозиция задачи, потом реализация хранилища в виде реляционной БД. Another way — is a wrong way!

Maybe.

ГВ>>4. Во время эксплуатации App-сервер собирает статистику по работе с БД и по необходимости

выполняется её оптимизация (это — почти как как всегда) с донастройкой маппинга.
IT>Вот это самое интересное. Жуть как хочется посмотреть на реализацию.

Ты себе представляешь объём подобного описания?

Нет уж, IT, извини.

Я тут и напостил достаточно много, почти приблизившись к раскрытию своих (и не только) know-how. Желающие могут додумать дальше, пуcть ищут свои пути.

Заодно — это очень помогает в интеллектуальном развитии и переоценке некоторых ценностей. А посмотреть на реализцию... ну, следите за прессой.

ГВ>>5. Да, чуть не забыл! все классы — persistable.
IT>Тоже не вопрос.
OK

IT>Пока не понятно как, давай развивать мысль.
Только не сейчас и уж тем более — не в форуме.

Резюмируя, могу тебе немного подсказать, где искать — начни с того, что я написал в первой части этого постинга относительно постановки задачи.

Да, кстати, можешь считать, что я вышел из спора некорректным образом.

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

ГВ>>>Что это за "таблицы"? Знать не знаю такого зверя!

Есть классы, объекты и отношения объектов.

IT>>Есть задача, которую надо решить

ГВ>Истинно так, и к таблицам она до поры до времени не имеет никакого отношения.

Понимаю, объектная модель для тебя первична. Ok, посмотрим что из этого получится.

ГВ>>>3. Структура БД и операций с ней выводится из этой схемы (информации для этого достаточно).
IT>>Структура БД уже определена условиями задачи. Но предложи свой вариант, интересно будет посмотреть.
ГВ>А вот ничего подобного — структуру БД будем определять после объектной декомпозиции. Повторяю — сначала объектная декомпозиция задачи, потом реализация хранилища в виде реляционной БД. Another way — is a wrong way!

Maybe.

Это хорошо что ты поставил смайлики и употребил наречие, означающее сомнение

ГВ>>>4. Во время эксплуатации App-сервер собирает статистику по работе с БД и по необходимости

выполняется её оптимизация (это — почти как как всегда) с донастройкой маппинга.
IT>>Вот это самое интересное. Жуть как хочется посмотреть на реализацию.
ГВ>Ты себе представляешь объём подобного описания?

Естественно, исходные тексты этой задачи (без формирования html) помещаются на одну печатную страницу

Могу показать. Причём моя реализация ни чуть не менее объектна твоей.

ГВ>Нет уж, IT, извини.

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

Правильно, думаю, что это лучше никому не показывать и вообще об этом не рассказывать

ГВ>Резюмируя, могу тебе немного подсказать, где искать — начни с того, что я написал в первой части этого постинга относительно постановки задачи.

Да, кстати, можешь считать, что я вышел из спора некорректным образом.

Спасовал, короче. В приципе, правильно. Ты наверное уже понял к чему я клоню

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

В общем, если спустится с облачков Буча на землю, то система окажется не живая.

В дополнение. Есть две ошибки, которые допускают начинающие проектировщики. Первая, попытка сделать всё максимально универсальным и очень объектным. Вторая, игнорирование при проектировании вопросов организации структуры базы данных, с которых в общем-то нужно всегда начинать. Непонимание этого — это big mistake, просто huge.

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

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

Мой ответ, в основном, предназначен для mvg_first.

ГВ>>>>3. Структура БД и операций с ней выводится из этой схемы (информации для этого достаточно).
IT>>>Структура БД уже определена условиями задачи. Но предложи свой вариант, интересно будет посмотреть.
ГВ>>А вот ничего подобного — структуру БД будем определять после объектной декомпозиции. Повторяю — сначала объектная декомпозиция задачи, потом реализация хранилища в виде реляционной БД. Another way — is a wrong way!

Maybe.

IT>Это хорошо что ты поставил смайлики и употребил наречие, означающее сомнение

Ну, не сомневаются только сумасшедшие и те кто не потеет.

ГВ>>>>4. Во время эксплуатации App-сервер собирает статистику по работе с БД и по необходимости

выполняется её оптимизация (это — почти как как всегда) с донастройкой маппинга.
IT>>>Вот это самое интересное. Жуть как хочется посмотреть на реализацию.
ГВ>>Ты себе представляешь объём подобного описания?

IT>Естественно, исходные тексты этой задачи (без формирования html) помещаются на одну печатную страницу

Могу показать. Причём моя реализация ни чуть не менее объектна твоей.

Да, значит, ты не представляешь о чём речь... досадно.

ГВ>>Нет уж, IT, извини.

Я тут и напостил достаточно много, почти приблизившись к раскрытию своих (и не только) know-how.
IT>Правильно, думаю, что это лучше никому не показывать и вообще об этом не рассказывать

До чего же нравится мне твоя самоуверенность.

Ну просто достойно упоминания в анналах.

ГВ>>Резюмируя, могу тебе немного подсказать, где искать — начни с того, что я написал в первой части этого постинга относительно постановки задачи.

Да, кстати, можешь считать, что я вышел из спора некорректным образом.

IT>Спасовал, короче. В приципе, правильно. Ты наверное уже понял к чему я клоню

Естественно.

Только не спасовал — мы с тобой играли на разных полях.

Или ты думал что я на "слабо" поведусь?

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

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

Кстати, коль не секрет, а синглетоны ты откуда взял?

Я вроде о них даже не упоминал? Попрошу тебя ответить в форуме хотя бы на этот пункт, на остальную часть поста можешь не отвечать.

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

Ну что же, частично ты прав.

Только есть одна недоработка — App-серверы ради организации форумов и одного запроса обычно не пишут. Хотя, мне было бы очень интересно узнать, каким образом обобщается твой подход на случай, ну, скажем, системы управления складом? Или для простоты возьмём более абстрактно: 170 таблиц, 600 запросов, из них, ну, скажем, 55 — групповые обновления, а ещё 80 — просто обновления для 2-3 таблиц. Да, ещё добавим к этому, что на 10 таблицах организованы древовидные классификаторы, которые участвуют в 50 запросах из указанных шестисот. Прикинешь цифру в человеко-годах? Да, ещё учтём, что в среднем в системе добавляется 5 новых запросов в месяц, 2 запроса трансформируется также ежемесячно, ещё 4 таблицы + 10 запросов появляются каждый квартал, а прогнозируемый жизненный цикл до полной замены — 7 лет. Как там насчёт сопровождения?

IT>В общем, если спустится с облачков Буча на землю, то система окажется не живая.

У Буча не такие уж и далёкие облачка. Всё зависит от высоты полёта.

IT>В дополнение. Есть две ошибки, которые допускают начинающие проектировщики. Первая, попытка сделать всё максимально универсальным и очень объектным. Вторая, игнорирование при проектировании вопросов организации структуры базы данных, с которых в общем-то нужно всегда начинать. Непонимание этого — это big mistake, просто huge.

Не спорю. Про структуру БД забывать вредно для здоровья системы. И разработчиков — нередко тоже.

[Внутренний голос: Скоро термин "не пойми меня правильно" войдёт в десятку наиболее многотрактуемых на RSDN.

]
IT>При этом, не пойми меня правильно, я совсем не против ООП, я всеми конечностями за. Но я пытаюсь поставить этот подход на службу моим задачам, а не бездумно служить ему самому.

Я в этом и не сомневался, IT. Кстати, представь себе — текстуально я того же мнения об ООП что и ты. Весь прикол этой ветки в том, что я отвечал тебе несколько не в том ключе, который ты от меня ожидал. Но ключ был задан исходной темой топика. Не находишь, что логичным было бы ожидать что любая тема, возникающая здесь, будет развиваться в контексте App-серверов?

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

При этом ты с ходу был готов контраргументировать любые мои построения тем, что эта узкая задача решается более компактно без App-сервера, нежели App-сервер под задачу (кастрированный, кстати) + решение задачи. Кто бы спорил! Из пушки-то по воробьям... Но App-серверы делают-то далеко не ради простейших задач. От твоего внимания ускользнуло, что задача выбрана ошибочно, и кстати я обратил твоё внимание на этот прокол.

Улавливаешь? Для перемещения на большие расстояния нужны самолёты, а "через дорогу" можно пройти и пешком. Но это не означает, что нужно на десять тысяч км топать ногами. Это весьма софистичный (и демагогичный, кстати) метод доказательства своей правоты (специально обращаю внимание mvg_first на это место).

А силлогизм, лежащий в его основе не имеет решения, да и силлогизмом, вобщем-то не является. Силлогизм таков. Посылка А: данную маленькую задачу можно решить простым способом за час. Посылка Б: App-сервер делается для сложных задач. Что из этого следует? Да то, что посылка А попросту неуместна в контексте данного топика.

Мне, в свою очередь, оставалось сказать только то, что я уже сказал — выкатить объектную модель и посмотреть на реакцию аудитории, коя оказалась по сути — нулевой.

Ну, было бы странно ожидать чего-то иного на 15-м уровне вложенности.

Ещё попытался сместить дискуссию в конструктивное русло, тоже, увы, не вышло...

Кстати (снова для mvg_first), следующий шаг "разгромщика" (домашнее задание 1. придумайте для него логичный эпитет, 2. откажитесь от этого эпитета, как от характеристики личности, эпитеты — только для характеристики доводов!) после такого "показательного" разгрома соперника — требование делать всё так, как он говорит.

Без всяких там App-серверов и прочих изысков... Впрочем это возможно только если "жертва" не успевает вовремя сориентироваться в пространстве.

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

IT>>Естественно, исходные тексты этой задачи (без формирования html) помещаются на одну печатную страницу

Могу показать. Причём моя реализация ни чуть не менее объектна твоей.

ГВ>Да, значит, ты не представляешь о чём речь... досадно.

Да куда нам деревенским

ГВ>>>Нет уж, IT, извини.

Я тут и напостил достаточно много, почти приблизившись к раскрытию своих (и не только) know-how.
IT>>Правильно, думаю, что это лучше никому не показывать и вообще об этом не рассказывать

ГВ>

До чего же нравится мне твоя самоуверенность.

Ну просто достойно упоминания в анналах.

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

ГВ>Естественно.

Только не спасовал — мы с тобой играли на разных полях.

Или ты думал что я на "слабо" поведусь?

Я у тебя конкретно спросил как. Ты сказал, что мол долго объяснять, ноу-хау и пр. Разве не так.

ГВ>Кстати, коль не секрет, а синглетоны ты откуда взял?

Я вроде о них даже не упоминал? Попрошу тебя ответить в форуме хотя бы на этот пункт, на остальную часть поста можешь не отвечать.

Разве нет? Значит я что-то попутал. В любом случае твоя модель стейтфул, без пары синглетонов там не обойтись.

ГВ>Ну что же, частично ты прав.

Только есть одна недоработка — App-серверы ради организации форумов и одного запроса обычно не пишут.

Это скорее зависит от нагрузки на этот самый форум.

ГВ>Хотя, мне было бы очень интересно узнать, каким образом обобщается твой подход на случай, ну, скажем, системы управления складом?

Сколько наименований номенклатуры? Примерный приход, расход в день? Выписка? Сколько поставщиков, потребителей? Осуществляется ли электронный обмен данными с поставщиками потребителями или всё ручками? Территориальная распределённость системы, синхронизация данных? Импорт/экспорт данных из/в бухгалтерию или всё в реальном времени? И т.п. Это всё гораздо интереснее чем:

ГВ>Или для простоты возьмём более абстрактно: 170 таблиц, 600 запросов, из них, ну, скажем, 55 — групповые обновления, а ещё 80 — просто обновления для 2-3 таблиц. Да, ещё добавим к этому, что на 10 таблицах организованы древовидные классификаторы, которые участвуют в 50 запросах из указанных шестисот. Прикинешь цифру в человеко-годах? Да, ещё учтём, что в среднем в системе добавляется 5 новых запросов в месяц, 2 запроса трансформируется также ежемесячно, ещё 4 таблицы + 10 запросов появляются каждый квартал, а прогнозируемый жизненный цикл до полной замены — 7 лет. Как там насчёт сопровождения?

Всё это совсем не показатель крутизны системы. Поверь мне

Я делал склад, который держал (может и сейчас держит) несколько крупных предприятий. Всё нормально, такого количества таблиц мне не надо было. Сейчас я работаю над системой, которая покруче описанной тобой и моя задача сделать её проще, гораздо проще чем то что описал ты. Там где есть 10 таблиц оставить 3, там где есть древовидные структуры попытаться от них избавиться, по-крайней мере это нужно сделать в рабочих таблицах, и т.д. Т.е. сделать систему проще, компактнее, быстрее, надёжнее и одновременно гибче.

ГВ>[Внутренний голос: Скоро термин "не пойми меня правильно" войдёт в десятку наиболее многотрактуемых на RSDN.

]

Это старый прикол, копирайт не мой

ГВ>Я в этом и не сомневался, IT. Кстати, представь себе — текстуально я того же мнения об ООП что и ты. Весь прикол этой ветки в том, что я отвечал тебе несколько не в том ключе, который ты от меня ожидал. Но ключ был задан исходной темой топика. Не находишь, что логичным было бы ожидать что любая тема, возникающая здесь, будет развиваться в контексте App-серверов?

Мы о них и говорим.

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

1. Ты в праве предложить свою.
2. Это задача которую нужно решать. Наверняка подобных задач в твоём складе вагон и маленькая тележка.

ГВ>При этом ты с ходу был готов контраргументировать любые мои построения тем, что эта узкая задача решается более компактно без App-сервера, нежели App-сервер под задачу (кастрированный, кстати) + решение задачи.

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

ГВ>Кто бы спорил! Из пушки-то по воробьям... Но App-серверы делают-то далеко не ради простейших задач. От твоего внимания ускользнуло, что задача выбрана ошибочно, и кстати я обратил твоё внимание на этот прокол.

Улавливаешь?

Она выбрана не ошибочно, это сделано специально. Это реальная задача из реальной жизни, задача, которую каждый может пощупать сам.

ГВ>Для перемещения на большие расстояния нужны самолёты, а "через дорогу" можно пройти и пешком. Но это не означает, что нужно на десять тысяч км топать ногами. Это весьма софистичный (и демагогичный, кстати) метод доказательства своей правоты (специально обращаю внимание mvg_first на это место).

А силлогизм, лежащий в его основе не имеет решения, да и силлогизмом, вобщем-то не является. Силлогизм таков.

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

ГВ>Посылка А: данную маленькую задачу можно решить простым способом за час. Посылка Б: App-сервер делается для сложных задач. Что из этого следует? Да то, что посылка А попросту неуместна в контексте данного топика.

Т.е. в маленькой системе такую задачу можно сделать за час, в большой нужен месяц?

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

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

IT, ты просто неутомим.

IT>>>Естественно, исходные тексты этой задачи (без формирования html) помещаются на одну печатную страницу

Могу показать. Причём моя реализация ни чуть не менее объектна твоей.
ГВ>>Да, значит, ты не представляешь о чём речь... досадно.
IT>Да куда нам деревенским

Хм. Тебе видней, но эмоции, наверное, лучше при себе оставить.

ГВ>>>>Нет уж, IT, извини.

Я тут и напостил достаточно много, почти приблизившись к раскрытию своих (и не только) know-how.
IT>>>Правильно, думаю, что это лучше никому не показывать и вообще об этом не рассказывать

ГВ>>

До чего же нравится мне твоя самоуверенность.

Ну просто достойно упоминания в анналах.

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

Угу, удобно. Давай пока рассмотрим декомпозицию.

ГВ>>Естественно.

Только не спасовал — мы с тобой играли на разных полях.

Или ты думал что я на "слабо" поведусь?

IT>Я у тебя конкретно спросил как. Ты сказал, что мол долго объяснять, ноу-хау и пр. Разве не так.

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

ГВ>>Кстати, коль не секрет, а синглетоны ты откуда взял?

Я вроде о них даже не упоминал? Попрошу тебя ответить в форуме хотя бы на этот пункт, на остальную часть поста можешь не отвечать.
IT>Разве нет? Значит я что-то попутал. В любом случае твоя модель стейтфул, без пары синглетонов там не обойтись.

Вопрос 1. Где эти singletons по твоему мнению должны быть?
Вопрос 2. Почему их присутствие должно влиять на load balancing?

Второй вопрос на самом деле — основной.

ГВ>>Ну что же, частично ты прав.

Только есть одна недоработка — App-серверы ради организации форумов и одного запроса обычно не пишут.
IT>Это скорее зависит от нагрузки на этот самый форум.

Э-э-э... ну смотря что считать App-сервером. Серверный "бизнес-компонент", даже пользующийся какой-то приблудой, реализующей те или иные сервисные функции я вот, как бы App-сервером не считаю...

ГВ>>Хотя, мне было бы очень интересно узнать, каким образом обобщается твой подход на случай, ну, скажем, системы управления складом?
IT>Сколько наименований номенклатуры? Примерный приход, расход в день? Выписка? Сколько поставщиков, потребителей? Осуществляется ли электронный обмен данными с поставщиками потребителями или всё ручками? Территориальная распределённость системы, синхронизация данных? Импорт/экспорт данных из/в бухгалтерию или всё в реальном времени? И т.п. Это всё гораздо интереснее чем:

Наверное интереснее, но вот в форуме меряться... эээ... силой не хочется. Речь, напоминаю, была о том, как обобщается твой подход (сначала разобраться с базой данных, оптимизировать её и т.п.) на достаточно сложную систему.

ГВ>>Или для простоты возьмём более абстрактно: 170 таблиц [bla-bla-bla]

IT>Всё это совсем не показатель крутизны системы. Поверь мне

А причём тут задачи App-серверов? Хотя я тоже неправ — нельзя сравнивать системы, полученные "реляционным" дизайном с системами, спроецированными на РСУБД из объекной декомпозиции.

IT>Там где есть 10 таблиц оставить 3, там где есть древовидные структуры попытаться от них избавиться, по-крайней мере это нужно сделать в рабочих таблицах, и т.д. Т.е. сделать систему проще, компактнее, быстрее, надёжнее и одновременно гибче.

Угу, занимаешься реинжинирингом системы. Сия фаза присутствует в ЖЦ любого живого софта. И что теперь? Реинжниринг сложной и бестолковой БД сопряжён с такими же геморроями, как и реинжиниринг корявой ОО-системы с размазанными и чёрт-те как выстроенными абстракциями.

ГВ>>Я в этом и не сомневался, IT. Кстати, представь себе — текстуально я того же мнения об ООП что и ты. Весь прикол этой ветки в том, что я отвечал тебе несколько не в том ключе, который ты от меня ожидал. Но ключ был задан исходной темой топика. Не находишь, что логичным было бы ожидать что любая тема, возникающая здесь, будет развиваться в контексте App-серверов?

IT>Мы о них и говорим.

Да, но как ты верно подметил ниже, похоже, что мы понимаем под этим очень разные вещи. Давай уточним, что ты понимаешь под App-сервером.

IT>1. Ты в праве предложить свою. [задачу, которая "катит"]
Не в кокнретных задачах дело, IT, а в подходе к их решению, который и приводит к необходимости решения в виде целостного App-сервера.

IT>2. Это задача которую нужно решать. Наверняка подобных задач в твоём складе вагон и маленькая тележка.
Какая разница — склад, бухгалтерия и т.п.

Дело в другом — в точке зрения на реализацию.

IT>Естественно, задача была подобрана специально что-бы показать, что ОО подход иногда не рулит. А апп-сервер здесь совсем не причём. Объектная модель и апп-сервер не одно и тоже и мой пример как раз и демонстрирует, что часто они не очень-то и совместимы.

Тогда зачем она здесь нужна? Это и так все отлично понимают, не дети, чай. Знаешь, есть задачи, вполне жизненные, в которых Java не рулит, или C++ не рулит, или CLR не рулит, даже Asm и тот не рулит. А мы подразумеваем здесь те задачи, в которых App-серер рулит. Если тебе удалось реализовать отдельные такие задачи без App-сервера — очень хорошо, но в целом это не имеет никакого значения.

Да, объектные модели бывают разными — есть объектные модели таблиц, и есть объектные модели приложений и что с того? Ответ — ничего.

IT>Она выбрана не ошибочно, это сделано специально. Это реальная задача из реальной жизни, задача, которую каждый может пощупать сам.

Никто с этим не спорит.

Что же теперь? Проблема в том, что не всегда исходные "привычные" методы декомпозиции, адекватные маленьким задачам достаточно адекватны большим.

ГВ>>Для перемещения на большие расстояния нужны самолёты, а "через дорогу" можно пройти и пешком. Но это не означает, что нужно на десять тысяч км топать ногами. Это весьма софистичный (и демагогичный, кстати) метод доказательства своей правоты (специально обращаю внимание mvg_first на это место).

А силлогизм, лежащий в его основе не имеет решения, да и силлогизмом, вобщем-то не является. Силлогизм таков.

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

Вопрос в том — как делить, какие функции где оставлять и вот тут для больших и маленьких задач всё может очень сильно отличаться. Ну как отличаются enum currency {USD, RUR}; от классификатора валют в БД. Мне попадались и такие проекты, где классификаторы валют enum-ом делают. Тоже — живые в своём роде. Что же теперь? Говорить, что всё и вся нужно сводить к enum-ам?

IT>К тому же большие, сложные, монстроидальные системы чаще говорят о плохом дизайне или вообще о его полном отсутствии.

Угу. не спорю. В частности, сколько монолитного монстра не оптимизируй — всё равно возни с ним будет много. Притом основная возня даже не с оптимизацией, а с модификациями, которые вызывают лавинообразную переработку оптимизаций окружающих узлов.

ГВ>>Посылка А: данную маленькую задачу можно решить простым способом за час. Посылка Б: App-сервер делается для сложных задач. Что из этого следует? Да то, что посылка А попросту неуместна в контексте данного топика.

IT>Т.е. в маленькой системе такую задачу можно сделать за час, в большой нужен месяц?

Странный вывод.

Я же ясно сказал, что этот силлогизм не имеет решения. Кроме того, что неуместно подсовывать задачку, подразумевая при этом заведомо некорректное с твоей точки зрения решение.

IT>Скорее всего у нас с тобой принципиально различные взгляды на апп-сервер и его место в системе. Соответственно мы по разному представляем и задачи, которые он должен решать.

Что представляешь ты?

	От:	mvg_first
	Дата:	08.02.03 19:17
	Оценка:

От:	IT	linq2db.com
Дата:	08.02.03 20:04
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	08.02.03 20:50
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	08.02.03 20:50
Оценка:	1 (1)

	От:	Igor Soukhov
	Дата:	09.02.03 09:30
	Оценка:	10 (1) +1

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	09.02.03 15:41
Оценка:	33 (2) -2

От:	DarkGray	http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата:	10.02.03 11:19
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	10.02.03 13:34
Оценка:

	От:	George Seryakov
	Дата:	10.02.03 20:10
	Оценка:

От:	Хитрик Денис	RSDN
Дата:	11.02.03 14:06
Оценка:

От:	cMex	ICQ: 99722815
Дата:	12.05.03 21:34
Оценка: