Здравствуйте, люди.

Рассудите. Есть такая ситуация... Есть 4 отдельных проекта. Один из которых гораздо больше (причем в виде одного здорового екзешника) и старше остальных. Существуют они как COM-объекты и общаются между собой соответственно. Есть мнение, что COM-интерфейс слишком медленный и надо все проекты слить в один большой, под управление этого самого большого объекта. Т.е. даётся мне этот мега проект, в виде дцу-шек и я в в него вставляю свой проект — мотивация что будет быстрее и проще Насколько разумно городить такое чудовище?

.

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

lgb>.

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

Аноним — это я, romannn_g

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

А>большой проект — редактор карт. А проекты поменьше — это программы для работы с различной текстовой информацией, которая частично находит своё отображение на карте. У каждого проекта своя БД и своя конкретная задача.

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

Мое мнение: код надо писать так, чтобы исходники можно было собирать как в DLL так и в EXE. Организовать один единый проект можно также модульно как и несколько. Есть приемущества COM объектов, которые возможно сейчас неочевидны для проекта, но потом могут понадобиться. А попробовав в различных вариантах (проект и COM объекты) можно написать Performances и однозначно сказать что лучше исходя из соображений скорости. Заодно и нам напишите что лучше?!

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

_>Здравствуйте, люди.

_>Рассудите. Есть такая ситуация... Есть 4 отдельных проекта. Один из которых гораздо больше (причем в виде одного здорового екзешника) и старше остальных. Существуют они как COM-объекты и общаются между собой соответственно. Есть мнение, что COM-интерфейс слишком медленный и надо все проекты слить в один большой, под управление этого самого большого объекта. Т.е. даётся мне этот мега проект, в виде дцу-шек и я в в него вставляю свой проект — мотивация что будет быстрее и проще Насколько разумно городить такое чудовище?
Нет, нет, нет. Только pas файлы. Только тогда можно о чём то говорить

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

_>Здравствуйте, люди.

_>Рассудите. Есть такая ситуация... Есть 4 отдельных проекта. Один из которых гораздо больше (причем в виде одного здорового екзешника) и старше остальных. Существуют они как COM-объекты и общаются между собой соответственно. Есть мнение, что COM-интерфейс слишком медленный и надо все проекты слить в один большой, под управление этого самого большого объекта. Т.е. даётся мне этот мега проект, в виде дцу-шек и я в в него вставляю свой проект — мотивация что будет быстрее и проще Насколько разумно городить такое чудовище?

Тут стоит идти по пунктам.

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

2. Применять COM для исключительно внутрипроектного общения — действительно перебор, только лишний геморрой. Что касается скорости — вопрос к тому, как часто происходят вызовы, может и существенно тормозить, а может и вовсе незаметно. Если ситуация такова, что каждый из этих "4 проектов" вызывается только из оставшихся трех проектов — ну и в баню этот COM. Я бы посоветовал задать себе простой вопрос: какова вероятность того, что некто захочет написать к этому плагин на, допустим, Visual Basic-е? Если существенна — COM лучше оставить, иначе..

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

Всем большое спасибо за ответы! Немного неожиданно "COM для исключительно внутрипроектного общения — действительно перебор, только лишний геморрой". Вообщем, я здесь услышал примерно те же доводы и предложения об исходниках, bpl, com, что и внутри нашего скромного коллектива. Лично мне ком импонирует тем, что приложения работают в разных адресных пространствах. Среди наших, как иронично подмечено "проектов" , часть пишется под активным контролем мемчека , а часть, мотивированные аргументами: "кривой этот ваш memcheck.pas, нифига он неправило показывает кучу утечек", успешно развиваются вылетая периодически с загадочными ошибками... Вообщем, хотелось, чтобы наши кривые руки как можно меньше пересекались в пароксизме кодописания.
Чтобы по этому поводу скажут, многоуважаемые обитатели этого форума. Буду очень рад культурным обвинениям в невежестве и поправкам в моём изложнении, так как по духу "вечный студент", стремлюсь к гармонии, к понтам не склонен

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

[Skip]
_> Среди наших, как иронично подмечено "проектов" , часть пишется под активным контролем мемчека , а часть, мотивированные аргументами: "кривой этот ваш memcheck.pas, нифига он неправило показывает кучу утечек", успешно развиваются вылетая периодически с загадочными ошибками... Вообщем, хотелось, чтобы наши кривые руки как можно меньше пересекались в пароксизме кодописания.
_>Чтобы по этому поводу скажут, многоуважаемые обитатели этого форума. Буду очень рад культурным обвинениям в невежестве и поправкам в моём изложнении, так как по духу "вечный студент", стремлюсь к гармонии, к понтам не склонен

Я использую FastMM, и пускай не гонят что он тоже криво показывает утечки
Все утечки в тему и их можна найти.