Вы бы использовали EnterpriseServices в новой корпоративной разработке? - PullRequest
Новая
       10

Вы бы использовали EnterpriseServices в новой корпоративной разработке?

2 голосов
/ 07 января 2009

Как вы, возможно, уже знаете, управляемый код (приложения .NET) может использовать COM + через EnterpriseServices , создавая такие проблемы, как распределенные транзакции , пул ресурсов и синхронизация «проще в программировании», потому что решения предоставляются COM + в качестве вспомогательной инфраструктуры для приложения.

Если ваши серверы приложений находятся в домене Windows, COM + "автоматически делает ваши приложения более масштабируемыми, обеспечивая пул потоков, пул объектов и своевременную активацию объектов. COM + также помогает защитить целостность ваших данных предоставляя поддержку транзакций, даже если транзакция охватывает несколько баз данных по сети " (источник MS)

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

Это будет большая система, но вы знаете, что со временем она может стать намного больше. Допустим, это что-то вроде большого ERP, с распределенными транзакциями, происходящими постоянно. Наконец, предположим, что ядро ​​системы будет находиться в домене Microsoft Windows ... делая выбор COM + через System.EnterpriseServices (ES). Вам нужно будет сделать некоторые компоненты доступными для третьих лиц, и вы можете сделать это через WCF.

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

Если ответ «нет», все ли услуги COM +, такие как распределенные транзакции , доступны и просты в использовании в полностью управляемой среде?

Ответы [ 2 ]

1 голос
/ 07 января 2009

Я бы не стал использовать EnterpriseServices, если вы еще не женаты на COM. Я думал о подобной проблеме этим утром, и если у вас есть опыт работы с COM, то EnterpriseServices - это находка. Двигаясь вперед, я бы выбрал более современную (.NET) инфраструктуру, потому что

  1. Проще найти разработчиков (и обучать)
  2. Программное обеспечение сторонних производителей будет ориентировано на .NET
  3. MS PSS более доступен для разработки .NET (я знаю, что они не прекращают поддержку COM, но попробуйте вызвать две разные проблемы и рассчитать время ответа)
0 голосов
/ 25 февраля 2009

номер

У нас не было конца проблем (в основном неразрешимых утечек памяти в COM + - вызванных различными битами взаимодействия COM +, на которые мы не могли повлиять), когда мы использовали .Net в COM +. Мы перешли на WCFServices, предоставляя функциональность бизнес-уровня, и свели наши распределенные транзакции к минимуму (т. Е. Транзакция завершена внутри службы WCF - единственный способ сделать это на самом деле). Использование встроенного .Net Transaction обрабатывает все, что нам нужно для транзакций.

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

...