Какая технология Delphi n-tier имеет низкую пропускную способность?

Question

Мне нужно развернуть приложение Delphi в среде, которая нуждается в централизованной системе хранения данных и файлов (для формирования изображений документов), но имеет несколько филиалов с относительно плохой связью. Я считаю, что лучше всего использовать 3-уровневое приложение для работы с базами данных, поэтому я могу предоставить богатые возможности рабочего стола с относительно небольшими потребностями в передаче данных. До сих пор я кратко рассмотрел Delphi Datasnap, kbmMW и Remobjects SDK. Кажется, что kbmMW и Remobjects SDK используют наименьшую пропускную способность. У кого-нибудь есть опыт развертывания любой из этих технологий в сложных средах со значительным числом пользователей (мне нужно поддерживать более 700)? Спасибо!

Answer 1

Следует помнить одну вещь: проблема заключается не в количестве пользователей, а в количестве пользователей, одновременно использующих ресурсы. Попытайтесь разработать ваше приложение «сервер без состояния», если это вообще возможно, это даст большую гибкость в долгосрочной перспективе, если вы обнаружите, что вам нужно добавить больше серверов в пул для поддержки вашей клиентской базы. Самое сложное в n-уровне - это масштабирование за пределы первого сервера ... планировать это с самого начала. Каждый запрос не должен ничего знать о предыдущем запросе ... или, по крайней мере, запрос должен иметь способ передачи контекста, чтобы сервер мог искать его в таблице сеанса или в чем-то подобном.

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

Answer 2

И kbmMW, и RO SDK предлагают двоичный формат, который более компактен, чем формат SOAP, особенно если вы работаете с документами.

RO SDK предлагает больше инструментов с графическим интерфейсом, чтобы помочь вам в ваших услугах.

Также взгляните на RealThinClient SDK , это легкая инфраструктура удаленного взаимодействия.

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

Answer 3

Зависит от того, привязаны ли вы к удаленным наборам данных. Если вы не привязаны к набору данных, то SOAP, вероятно, будет хорошим выбором. Или я написал свой собственный протокол, который по своей природе похож на SOAP. Это было сделано до того, как SOAP стал стандартным, и я рад, что я это сделал - это дает вам возможность контролировать большую часть потока данных. Считается, что если у вас плохая связь, вы будете тратить время на ее поддержку. Очень хорошо, если вы поддерживаете собственный код, а не ждать поставщика. (Хотя KBM и REM, как известно, являются довольно хорошими поставщиками.)

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

Answer 4

Я не знаю, является ли это самым лучшим / наиболее эффективным (рад, что вы задали этот вопрос!), Но у меня были хорошие результаты с RemObjects SDK + DataAbstract. Последний сделал большую часть деталей сантехники менее сложными, что было полезно. Все еще реализуем, но пока все хорошо.

Answer 5

Если вы действительно хотите перейти на «низкую пропускную способность», используйте BSD Sockets API - это даст вам полный контроль над тем, что отправляется, и вы можете отправлять как можно меньше информации. Конечно, тогда вам придется реализовать все уровни самостоятельно, но эй - это все еще опция : D