Здравствуйте, 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 и явного освобождения объекта. Кеш все таки предпочтительней, хотя его реализовать тяжелее, особенно в неуправляемых средах.

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

IT>>SQL сервер — сердце системы и к нему нужно относится бережно и трепетно, лелеять и холить.

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

Я хочу её дизайнить как максимально производительную.

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

ГВ>Да, только вся проблема — в согласовании этого слоя с остальными и в уменьшении возни с ним.

Именно поэтому и нужно иметь этот слой отдельным, что бы было меньше с ним возни

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

IT>На этих задачах можно состариться и так и не увидеть своё детище в производстве. Железный, проверенный способ поддержки распределённой нагрузки — stateless модель для объектов хранимых в базе данных. Stateful только для очень редкоизменяемых объектов.

Если ты внимательно читал — человек хочет энтити, т.е. стейтлесс модель идет лесом.

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

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

IT>stateless, только stateless.

Resin как то умудряется перегружать даже stateful, иногда даже после этого нет глюков.

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

DMV>Тем более что в .NET, насколько я знаю, нет особой поддержки (ASP.NET caching невсчет).

Там есть замечательная штука под названием WeakReference. Хотя конечно проблему синхронизации кешей в кластере это не решит.

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

AVK>Если ты внимательно читал — человек хочет энтити, т.е. стейтлесс модель идет лесом.

Он хотел и VC++, но теперь он уже тоже идёт лесом

AVK>Я в свое время делал это примерно так — была очередь обычных ссылок, при каждом запросе ссылка перемещалась в начало. Ссылки, вылезшие из очереди цеплялись через слабые ссылки.

А для поиска ещё один сортированный список объектов?

IT>>stateless, только stateless.

AVK>Resin как то умудряется перегружать даже stateful, иногда даже после этого нет глюков.

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

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

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

Какие здесь могут быть проблемы. Нравится C# — пиши на нем, нет — тогда VB7, все равно все скомпилится в MSIL, вообще-то даже на нем можно писать.

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

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

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

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

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

AVK>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Кстати, в литературе ты встретишь разные термины для обозначения одних и тех же вещей. Например, stateless подобен transitive в терминологии Шлеера, а stateful — persistable (аналогично).

AVK>Последнее не совсем верно. persistable = entity, stateful это более общий термин.

Да, пожалуй, что так ближе.

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

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

AVK>>Если ты внимательно читал — человек хочет энтити, т.е. стейтлесс модель идет лесом.

IT>Он хотел и VC++, но теперь он уже тоже идёт лесом
Не совсем верное утверждение — лесом пока ничего не идет. Просто, я дабы убрать излишниие недопонимания слегка перефразировал вопрос. Так как основное для меня осознать технологию и методы конструирования. А уже о языке я подумаю чуть позже — когда буду обладать более полной информацией о их возможностях и ограничениях.


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

Здравствуйте, 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 или что там будет). Привязкой к одному только объекту/классу здесь ничего не решишь.
Согласен

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

IT>>>SQL сервер — сердце системы и к нему нужно относится бережно и трепетно, лелеять и холить.

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

IT>Я хочу её дизайнить как максимально производительную.

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

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

ГВ>>Да, только вся проблема — в согласовании этого слоя с остальными и в уменьшении возни с ним.

IT>Именно поэтому и нужно иметь этот слой отдельным, что бы было меньше с ним возни

Вопрос в структуре этого слоя, только и всего.

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

AVK>>Я в свое время делал это примерно так — была очередь обычных ссылок, при каждом запросе ссылка перемещалась в начало. Ссылки, вылезшие из очереди цеплялись через слабые ссылки.

IT>А для поиска ещё один сортированный список объектов?

Зачем? Поиск по базе.

IT>Самое интересное, что из стейтлес можно всегда легко сделать стейтфул, а вот обратное неверно.

Вот о том и речь.

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

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

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

Здравствуйте, 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>Хотя если использовать промежуточные слои для "маскировки" механизмов работы с базами данных такой подход наверняка будет неприменим.