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

DAS>Систем сейчас куча и есть из чего выбрать, например — Axapta, Attain, SAP, Baan, Oracle Application, MFG, Галактика, Парус......

Прикол в том что ни одна из перечисленных тобой систем, ничем не управляет
это просто пассивные отчеты. Так что эти система туфта, и по функционанальности(основной)
такие же как и 1С, за исключением разных архитектур, реализаций и фич, которые
в общем то бизнесу кардинально ну никак не помогут. А бизнесу поможет только УПРАВЛЕНИЕ
так вот не одна из систем не дает этого, только данные для этого
а что толку их внедрять на предприятиях когда там сидят тупые управленцы, ничего не изменится,
ну разве что какой отчет покрасивше.
Так что даже написанная на фокспро простая управляющая система,
сделает для предприятия гораздо больше, чем разпиаренная аксапта и ко.

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


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

Наверное у тебя очень большой опыт работы с этими системами

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

S>>Чем обосновывается решение применять .NET или Java в ядре системы?

AVK>Надежнее код, нет утечек памяти, невозможна случайная порча памяти.

Здесь вы приводите тезисы, традиционно упоминаемые при сравнении С++ и более высокоуровневых языков типа C# и Java.
Да, согласен, С++ более требователен к разработчику чем Java и C#, это хорошо известно. Но вместе с тем это более гибкое и более скоростное решение. Так что такой аргумент меня не убеждает. Фактически вы утверждаете что С++ не годится потому, что он сложен. Ведь согласитесь, утечки и порча памяти — это проблемы кривого кода а не плохого языка. Давайте исходить из того, что над системой работают высокоуровневые программисты и сложность языка не имеет значения.
В такой ситуации какие преимущества у Java и С# перед С++?

Вообще надо сказать, что начиная с определенного уровня сложности задач, такой критерий как сложность языка совершенно теряется перед сложностью алгоритма и структур данных. И в такой ситуации необходимо делать выбор, основываясь на том, какие сопутствующие технологии существуют для того или иного языка. Например, совершенно логичен ваш пример относительно джаваы и сопутствующей ей технологиии EJB. Вот это я принимаю, и это действительно серьезный аргумент. Другое дело что качество реализации этой технологии — паршивое, и полезных вещей 40%. Остальное маркетинговые фишки, типа того, как круты и безальтернативны наши Entity Beans, и у MS ничего подобного нет. Но это уже конкретика. А общая идея в том, что давайте при принятии решений об использовании того или иного языка в ядре ERP будем руководствоваться мощьностью этого языка и близлежащих технологий.

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

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

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

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

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

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

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

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

Конечно, пока ты лабаешь порносайты из шести статических страниц и одного голосования, тебе этого не осознать. Твой стиль — дешево и сердито, и в этом нет ничего плохого. Просто сложность реализации должна быть адекватна ценности решенной задачи.

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

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

S>Мощность языка, крастота кода, оптимизация и прочая распальцовка — это факторы непосредственно определяющие качество результата. Эти факторы не являются романтикой, они определяют стиль программирования подход к решению задач в целом. Самоутвеждение здесь не причем, поверь.

S>Конечно, пока ты лабаешь порносайты из шести статических страниц и одного голосования, тебе этого не осознать. Твой стиль — дешево и сердито, и в этом нет ничего плохого.
S>Просто сложность реализации должна быть адекватна ценности решенной задачи.

Так и я о том же.

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

Упс! Пора бежать в прачечную
Не хотел обидеть. Ключевая фраза "в условиях ограниченных ресурсов", ИХМО, надо смотреть на конкретую задачу.

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

S>>>Чем обосновывается решение применять .NET или Java в ядре системы?
AVK>>Надежнее код, нет утечек памяти, невозможна случайная порча памяти.

S>Здесь вы приводите тезисы, традиционно упоминаемые при сравнении С++ и более высокоуровневых языков типа C# и Java.
S>Да, согласен, С++ более требователен к разработчику чем Java и C#, это хорошо известно. Но вместе с тем это более гибкое и более скоростное решение. Так что такой аргумент меня не убеждает. Фактически вы утверждаете что С++ не годится потому, что он сложен. Ведь согласитесь, утечки и порча памяти — это проблемы кривого кода а не плохого языка. Давайте исходить из того, что над системой работают высокоуровневые программисты и сложность языка не имеет значения.

Напоминаю: Java подавалась как "усовершенствование C++", C# рекламируется примерно также (на фоне кастрированного Managed C++).

S>В такой ситуации какие преимущества у Java и С# перед С++?

С учётом нижеизложенного требования надёжности и эффективности напоминаю: и Java и .Net используют garbage collector.

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

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

S>Но вместе с тем это более гибкое

Гибкость гибкости рознь. Кое в чем менеджед платформы куда гибче плюсов.

S>и более скоростное решение. Так что такой аргумент меня не убеждает.

Да ради бога. Я уже давно убедился что определенным людям доказать что в этом мире есть что то помимо С++ практически невозможно.

S> Фактически вы утверждаете что С++ не годится потому, что он сложен.

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

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

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

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

Высокоуровневые в плане профессионализма? Как правило реальная ситуация прямо противоположная.


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

Я бы так не сказал. Тем более что сложность ERP систем как правило не в алгоритмах, а в структуре и количестве.

S> Другое дело что качество реализации этой технологии — паршивое, и полезных вещей 40%.

Аргументы?

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

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

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

ГВ>Напоминаю: Java подавалась как "усовершенствование C++", C# рекламируется примерно также (на фоне кастрированного Managed C++).

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

Облегчение синтаксиса — да, но усовершенствования я здесь не вижу.

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

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


S>Вот если бы вы назвали некие преимущества, вернее возможности Java и C# не доступные C++, то я бы согласислся что это усовершенствование.

Так это они и есть — "тяжеловесные и медлительные контейнеры Java", "отсутствие контроля памяти разработчиком"...

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


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

Ну кое в чем возможно да. Упаси меня бог отрицать необходимость и мощь Java и C#. Моя задача — взвесить аргументы за и против и принять решение. Так что я очень ценю ваше мнение.

AVK>Да ради бога. Я уже давно убедился что определенным людям доказать что в этом мире есть что то помимо С++ практически невозможно.

Это не про меня. Я готов изменить свою точку зрения. Да согласен, мой основной опыт и знания лежат в плоскости С++. Тем не менее не могу сказать что я полный профан в J2EE. Я занимался этой технологией полтора года, занимался серьезно. Так что имею возможность сравнить. И на основание имеющегося у меня опыта и впечатлений, а также опыта ведущих разработчиков ERP (авторитет SAP я думаю вы не будете отрицать) я склоняюсь к С++.

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

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

AVK>Не соглашусь.

Ну это же просто глупо. Вы что хотите сказать что программа на С++ идеально написанная господом богом, все равно будет течь только из-за того что это С++? Другое дело, что многие разработчики, развращеные хреново работающими сборщиками мусора, просто ленятся следить за памятью. А между тем имено такой контроль как показывает практика — самый эффективный.

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

Вот именно — с премлемыми потерями. Утечки, которые дает Java не приемлемы в сверхкрупных приложениях.

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

S>> Другое дело что качество реализации этой технологии — паршивое, и полезных вещей 40%.

AVK>Аргументы?

Вообще-то я немного сказал об этом. Entity Beans — это действительно необходимые сущности или чистый маркетинг? Можно говорить дальше, можно говорить о качестве серверов приложений, но это уже философский спор.

Хотя это интнресно и я готов обсудить.

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

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

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

AVK>И кроме этого фактора существует масса других — например очень часто во главу угла при создании ERP ставят скорость разработки и надежность полученного кода, а мощность языка обычно этому помеха.

Давайте еще раз обрисуем приоритеты. Пусть основными требованиями для разрабатываемой ERP считаются отказоустойчивость и скорость работы. Время разработки — тоже достаточно важный, но все же второстепенный фактор по сравнению первыми двумя требованиями.

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

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


S>>Вот если бы вы назвали некие преимущества, вернее возможности Java и C# не доступные C++, то я бы согласислся что это усовершенствование.

G>Так это они и есть — "тяжеловесные и медлительные контейнеры Java", "отсутствие контроля памяти разработчиком"...

1. java.collection проигрывает STL по скорости, гибкости и предоставляемым возможностям.

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

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

S>а также опыта ведущих разработчиков ERP (авторитет SAP я думаю вы не будете отрицать)

А что SAP? Понятно что они конкурентов хвалить не будут.

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

AVK>>Не соглашусь.

S>Ну это же просто глупо. Вы что хотите сказать что программа на С++ идеально написанная господом богом, все равно будет течь только из-за того что это С++?

Идеальных программ не бывает. Как не бывает идеальных разработчков.

S>Другое дело, что многие разработчики, развращеные хреново работающими сборщиками мусора, просто ленятся следить за памятью.

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

S>Вот именно — с премлемыми потерями. Утечки, которые дает Java не приемлемы в сверхкрупных приложениях.

Какие утечки? И почему они неприемлемы?

S>Вообще-то я немного сказал об этом. Entity Beans — это действительно необходимые сущности или чистый маркетинг?

Необходимые сущности, бо в современных решениях в этой области часто реализуют что то похожее. И никто не заставляет использовать все возможности EJB. Понятно что в каких то случаях неприемлемы CMP, в каких то неприемлемы вобще entity beans, но это никоим образом не отменяет остальных возможностей EJB-серверов.

S>Тут — полностью согласен. Действительно, мощность и гибкость средства разработки должна быть ровно такой какая нужна для конкретного применения. Я и пытаюсь выяснить, мощность какого средства меня устроит.

Боюсь что для ERP систем (не для их ядра, а для того самого бизнес-кода) особой мощности и гибкости не нужно. Тот же упомянутый тобой SAP вобще считает что настройки должны быть декларативными.

S>Давайте еще раз обрисуем приоритеты. Пусть основными требованиями для разрабатываемой ERP считаются отказоустойчивость и скорость работы.
S>Время разработки — тоже достаточно важный, но все же второстепенный фактор по сравнению первыми двумя требованиями.

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

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

AVK>Идеальных программ не бывает. Как не бывает идеальных разработчков.

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

S>>Другое дело, что многие разработчики, развращеные хреново работающими сборщиками мусора, просто ленятся следить за памятью.

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

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

S>>Вот именно — с премлемыми потерями. Утечки, которые дает Java не приемлемы в сверхкрупных приложениях.

AVK>Какие утечки? И почему они неприемлемы?

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

S>>Давайте еще раз обрисуем приоритеты. Пусть основными требованиями для разрабатываемой ERP считаются отказоустойчивость и скорость работы.
S>>Время разработки — тоже достаточно важный, но все же второстепенный фактор по сравнению первыми двумя требованиями.

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

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

Здравствуйте, Slick, Вы писали:
S>Ну далеко не всегда. Думаю что при разработке внутренних систем автоматизации для NASA и нью-йорркской фондовой биржи, все же отказоустойчивость, скорость работы и надеженость будут поважнее времени разработки.
По случайности видел я системы в NASA. Ну это даже обсуждать не серьезно!
50% кода на ASM и зашита в ПЗУ — системы рельного времени. Встречаются также модули высокого уровня на Java.
Только пример выбран не верно! Разработка такой системы стоит милиарды. Ты в жизни потом ее не окупишь — это очень специфичные предметные области.

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

AVK>>Идеальных программ не бывает. Как не бывает идеальных разработчков.

S>Вот, о профессиональном уровне программистов я и говорил. Нечего на язык пенять, коли руки кривы.

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

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

S>Во всяком случае в плюсы не ограничивают возможности программиста в этом направлении.

Ну да, вот только GC там реализовать нормальный так и не удалось.

S>Утечки в Java приложениях можно только глубокомысленно созерцать, размышляя о бренности бытия.

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

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

Ага, при помощи пары месяцев траха.

AVK>>Какие утечки? И почему они неприемлемы?

S>Те утечки кторые имеют место из-за некорректной работы сборщика мусора.

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

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

S>Ну далеко не всегда.

Так практически всегда.

S>Думаю что при разработке внутренних систем автоматизации для NASA и нью-йорркской фондовой биржи,

Это не ERP в классическом понимании.

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

ГВ>>Напоминаю: Java подавалась как "усовершенствование C++", C# рекламируется примерно также (на фоне кастрированного Managed C++).
S>Это чистой воды маркетинг. Что занчит усовершенствование? Отсутствие множественного наследования, шаблонов и контроля памяти разработчиком — это что усовершенствование?
S>Тяжеловесные и медлительные контейнеры Java по сравнению с мощнейшим и гибким STL — это тоже усовершенствование?

Нет, разумеется.

S>Облегчение синтаксиса — да, но усовершенствования я здесь не вижу.

Я тоже.

S>Вот если бы вы назвали некие преимущества, вернее возможности Java и C# не доступные C++, то я бы согласислся что это усовершенствование.

Хех, я вижу у них обоих одну большую возможность, условно недоступную C++ — garbage collector => непредсказуемость задержек (об этом на RSDN, кстати, неоднократо упоминалось).

Ну а кроме шуток, Java и C# (вернее — .Net) — платформы, притом жёстко конкурирующие между собой, а С++ — язык, на котором они, кстати, написаны. Вернее — Sun/Java написана вообще на C. ИМХО, .Net — не плохая платформа, только она не для "ядерных" приложений, да и кроме неё, скорее всего и другие появятся. Где появились двое — там появилась возможность выбора => кто-то почти наверняка захочет расширить этот выбор.

Ещё учти, что на разработку "системного ядра" ERP при квалифицированных проектировщиках/С++-никах потребуется где-то 0,8-2 ч/года в зависимости от требований (ну это я по опыту), а на анализ и разработку предметных областей всё равно улетит в разы больше.

А потом, в принципе, никто не помешает тебе интегрироваться практически с любой из существующих платформ/инфраструктур, поскольку интерфейс для C по-любому у всех будет ещё ну очень долго.

Так что, я не вижу серьёзных преимуществ Java/.Net перед ядром на C++.

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


ГВ>Ещё учти, что на разработку "системного ядра" ERP при квалифицированных проектировщиках/С++-никах потребуется где-то 0,8-2 ч/года в зависимости от требований (ну это я по опыту), а на анализ и разработку предметных областей всё равно улетит в разы больше.

Просветите пожалуйста, что входит в понятие "системного ядра ERP". И чем ядро отличается от бизнесс-логики. И что на чем пишется.

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

S>2. Отсутствие контроля памяти в Java тем не менее приводит к написанию "текущих" приложений, порою изрядно текущих. Причина — качество сборщика мусора. Если тебе нужно идеальное в смысле утечек приложение, иного способа кроме самоконтроля — не найдешь.

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

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

ГВ>>Ещё учти, что на разработку "системного ядра" ERP при квалифицированных проектировщиках/С++-никах потребуется где-то 0,8-2 ч/года в зависимости от требований (ну это я по опыту), а на анализ и разработку предметных областей всё равно улетит в разы больше.
А>Просветите пожалуйста, что входит в понятие "системного ядра ERP". И чем ядро отличается от бизнесс-логики. И что на чем пишется.

Само по себе это понятие определяется в зависимости от того кому как приспичит и кто что продвигает. Вот моё мнение, исходя из предпочитаемой мной "сервероцентрической" архитектуры:

Ядро

1. Поддержка ЖЦ "прикладных" объектов;
   
2. Поддержка взаимодействия с пользователем (трансформация отображения — в том числе);
   
3. Объектно-реляционное отображение (как минимум — CRUD + транзакции + кеширование);
   
4. Поддержка работы в кластере;
   
5. Управление доступом;
   
6. Управление памятью;
   
7. Управление локализацией;
   
8. Контроль версий прикладного софта;
   
9. Управление deployment-ом.

Как дополнение — административные "фенечки" и контрольные механизмы: всякие счётчики, сбор статистики, run-time оптимизация и т.п.

Драйверы, подключаемые к ядру

1. Адаптеры компонентных инфраструктур (более низкий уровень — сетевые драйверы);
   
2. Драйверы хранилищ данных;
   
3. Драйверы тонких клиентов (Web-servers-API, собственный клиент);
   
4. Драйверы генерации отчётов (не забываем, что отчёты — частный случай отображения).

Дополнительно — адаптеры взаимодействия с другими программами.

Прикладная логика — пишется на том же языке, что и ядро по некоторым соглашениям (наследование от... и т.п.) + библиотеки связи с ядром. Как вариант — использование чего-то вроде VBS для прикладной логики.

В идеале — код прикладной логики полностью освобождается от "системных" аспектов — только собственно прикланая логика + декларативные элементы описания особенностей ЖЦ, persistability, отображения пользователю и т.п. (2AVK: да-да, а-ля атрибуты .Net )