Просто перевёл ПРОМТом:
Кто может художественней, you welcome!





-----------------------Страница 1-----------------------

Двигение в .NET от PowerBuilder: Перспектива для Разработчиков Клиент-сервер

Группа Систем Бесконечности Архитектора Решений Шона Флайнна, управление логическим звеном

-----------------------Страница 2-----------------------

Оглавление

Introduction3
PowerBuilder History.3
Что является DevForce? ....4
Доступ к данным PowerBuilder Layer..............4
Объект{Цель} DevForce, Относительный Mapping........4
Нет SQL?....6
Настройка Бизнеса Objects..7
Сохранение Данных ...............8
Переплет{Связывание} Данных к UI ...............9
Хозяин / Деталь .........10
Богатые Управления ...........10
Кэширование ...11
Недоступно Операции ..12
Архитектура N-ряда ..12
Масшабируемость и Надежность ......... 13
Досягаемость ......13
Security....13
Конфигурация и Развертывание 13
Visual Studio IDE.....13
Товары Продукта .......14
Итог .14
Заключение ...............14

-----------------------Страница 3-----------------------

Двигение в .NET от PowerBuilder/3

Введение

Как разработчик PowerBuilder в течение больше чем 15 лет, я всегда приводил осторожный глаз на новые тенденции развития, поскольку они относятся к производительности разработчика. Я плескался с приложениями J2EE и ранее .NET технологии, но я всегда возвращался к PowerBuilder, поскольку его аспектом производительности был всегда по крайней мере порядок величины выше.
С выпуском комплекта инструментальных средств DevForce от IdeaBlade там наконец, кажется, стек технологии, который является доступным и обеспечивает производительность разработчика на паритете с PowerBuilder. Важно отметить, что я не служащий IdeaBlade, и при этом мне не платили, чтобы написать эту бумагу{газету}.

PowerBuilder - среди самых производительных и удобных доступных платформ разработки приложений клиент-сервер. Разработчики PowerBuilder особенно любят управление DataWindow, которое последовательно сравнивается благоприятно с его конкурентами. Тем не менее, есть коммерческие силы, управляющие даже самым лояльным, чтобы рассмотреть перемещение к .NET, поскольку PowerBuilder теперь замечен как "устаревшая" технология.

К сожалению, родной, "из поля" .NET - явно среда запрещения. Есть немного конструкций приложения высокого уровня, конечно ничто приближающееся к DataWindow. Языковые выборы отличны. Парадигма объекта{цели} незнакома. Сложности - многие, и кривая изучения крута.

В этой бумаге{газете}, мы описываем путь .NET, используя IdeaBlade DevForce структура. Путь обещает более плоскому .NET изучение кривой и опыта friendlier, чем если бы один занялся .NET один. Разработчик PowerBuilder найдет самые важные функции PowerBuilder представленными (хотя выражено по-другому) и может ожидать по крайней мере сопоставимую производительность. Кроме того, есть потенциал для того, чтобы строить приложения с большими возможностями{контекстом}, властью{мощью}, безопасностью, и досягаемость чем возможна для большинства разработчиков PowerBuilder сегодня.

Хронология PowerBuilder

PowerBuilder был запущен в начале 90-ых, когда Дейв Литвак распознал, что существующие инструментальные средства для Windows развитие клиент-сервер не были до задачи для приложений клиент-сервер предприятия. PowerBuilder быстро переместил{заместил} единственную другую существующую интегрированную среду разработки Windows в то время, SQLWindows Гаптаа, из-за его инновационного объектно-ориентированного подхода к развитию. К середине 90-ых PowerBuilder твердо утвердился как промышленный стандарт для развития клиент-сервер для многих ведомственных и приложений независимого поставщика оборудования. В течение этого периода, многочисленного 3-ий

партийные структуры прибыли к рынку, который резюмировал многие из общих{обычных} задач развития, которые драматично увеличили производительность разработчика. Sybase освобождал его собственную структуру, Фундаментальные классы PowerBuilder (PFC), используя подход на основе обслуживания{службы}, который быстро утвердился основание для многих заказных в структурах фирмы.
Наследование объекта{цели} Пауэрбуилдера и структуры, которые это поддерживало, были ведущим фактором для его преобладания над его конкурентами, включая Microsoft.

К этому дню никакое другое инструментальное средство не может соответствовать производительности Пауэрбуилдера для того, чтобы разработать центральные данными приложения клиент-сервер. После приобретения PowerSoft в конце 1990-ых Sybase, наряду со многими из продавцов времени, поворачивал его центр к прикладному развитию сервера в надеждах, что все развитие двигалось в Сеть.
К сожалению этот сдвиг в центре прибыл по существенной стоимости Пауэрбуилдеру, так что в итоге продукт подвергся относительно немногим расширениям в течение нескольких лет. Как только прикладной рынок сервера “вытряхнул,” оставляя только горстку существенных игроков, Sybase наконец возвращал его внимание Пауэрбуилдеру, но к тому времени продукт упал далеко позади в функциональности.

Sybase делает попытку законного возвращения с Пауэрбуилдером 11 с родной поддержкой .NET 2.0 и шикарному{умному} клиентскому развертыванию, но разработчики все еще сдержаны к тому, что может быть создано со стандартным приложением PowerBuilder, которое весьма ограничено когда по сравнению с Visual Studio Microsoft. Хотя Пауэрбуилдер все еще уместен, особенно в течение последнего Ренессанса развития клиент-сервер, маловероятно, что Sybase будет в состоянии усовершенствовать это с передовыми технологиями. .NET 3.0 и Фонд{Основа} Представления Windows (WPF), который поддержка обещается для будущего выпуска, но будет трудно модифицировать в среду Пауэрбуилдера. В результате вычислительные центры Пауэрбуилдера все более и более находят себя неспособными поставить передовым технологиям их запрос клиентов.

-----------------------Страница 4-----------------------

Двигение в .NET от PowerBuilder/4

Что является DevForce?

DevForce - .NET-базируемая структура для того, чтобы строить управляемые данными, распространенные, богатые интернет-приложения. Ниже этих типов приложений постоянно находится уровень инфраструктуры - "слесарного дела" - который является родовым, универсальным и неуклонно трудным написать и поддерживать{обслуживать}. И DevForce и Пауэрбуилдер обеспечивают существенные части той инфраструктуры так, чтобы разработчики могли сконцентрироваться на программировании делового значения. Основные содействия{вклады} Девфорс находятся в организации данных (через ORM и Сервер Постоянства), представление данных (через databinding), и масштабируемый, развертывание n-ряда - все изнутри собственной интегрированной среды обработки Visual Studio .NET (интегрированная среда разработки). Пауэрбуилдер также силен на организации данных и представлении. Давайте сравнивать два в каждой из этих областей.

Уровень Доступа к данным Пауэрбуилдера

Основное транспортное средство для доступа к данным и дисплея данных в Пауэрбуилдере - управление DataWindow. Большинство приложений PowerBuilder использует те же самые объекты{цели} DataWindow и для представления и для доступа к данным. Хотя это может ускорить развитие, эта плотная{напряженная} связь также означает графический интерфейс пользователя, и развитие доступа к данным часто выполняется тем же самым разработчиком. Разработчик Пауэрбуилдера должен демонстрировать близкое знание базы данных и ее структуры объектов{целей}, включая их связи. Например, разработчик должен знать, когда использовать объединение по эквивалентности против внешнего объединения.

SELECT ordersummary.id, … shipper.companyname, сумма (количество * unitprice) как Общее количество FROM ordersummary
JOIN orderdetail
ON orderdetail.ordersummaryid = ordersummary.id LEFT OUTER грузоотправитель JOIN ON shipper.id = ordersummary.shipperid GROUP BY ordersummary.id, … shipper.companyname

Он или она должен знать таблицы, обозрения, области{поля}, и процедуры по имени - их именами схемы базы данных - и получающимся приложением всегда уязвимы для даже простых изменений{замен} схемы. Разработчики больших приложений стремятся заключить в капсулу{кратко изложить} большую часть этой логики для многократного использования, согласованности, и меры независимости схемы. Такие усилия являются типично специальными и домашними выращенными.

Объект{Цель} Девфорс Относительное Отображение

Девфорс продвигает объектно-ориентированный подход к формированию пакета уровня данных, стратегия по имени Относительное объектом{целью} Отображение (ORM). В этом подходе, программист объявляет отображение между деловыми свойствами объекта{цели} и соответствующими элементами базы данных. Она тогда полагается на “PersistenceManager”, чтобы выполнить операции базы данных как предписано отображением. PersistenceManager знает, как отыскать объекты{цели} и когда сделать так. PersistenceManager гарантирует деловую целостность и осуществляет оптимистический параллелизм в течение, сохраняет. В обоих случаях, это управляет ошибками доступа к данным последовательно и изящно. Внимание программиста находится на объектах{целях} непосредственно, и расценивает их почти, как будто они были готовы и доступны в памяти как раз в то самое время, когда они необходимы.

Объектно-ориентированная абстракция данных ORM более изящна, более выразительна, и в конечном счете более безопасна чем более традиционный отчет{рекорд} Пауэрбуилдера и модель столбца. Рассмотрите общую{обычную} задачу "навигации" от главного отчета{рекорда} до его подробных отчетов{рекордов}, от "заказа{порядка}" до его “отчетов{рекордов}” детали заказа{порядка}. Типичный разработчик Пауэрбуилдера создал бы объект{цель} DataWindow, основанный на запросе, типа:

-----------------------Страница 5-----------------------

Двигение в .NET от PowerBuilder/5

Выберите список столбцов от OrderDetails где order_id =:OrderId

Усилие требует знания SQL синтаксиса и точных имен объектов базы данных (, типа “OrderDetails” и ", order_id”). SQL-операторы быстро становятся длинными и непослушными. Компания передала под мандат соглашения об именах базы данных, добавляют к беспорядку{замешательству}, поворачивая наше простое SQL в

Выберите RPN_ORDER_ID, RPN_RPP_PRODUCT_ID, RPP_PRODUCT_NAME, … от RPL_ORDERDETAILS, RPP_PRODUCT где RPN_ORDER_ID = {Строка Заказа{Порядка}. Id} и RPN_RPP_PRODUCT_ID = RPP_PRODUCT_ID

Три месяца в проект, даже автор нуждался бы в нескольких минутах, чтобы обнаружить то, что это делает и почему это делает это этот путь.

Большинство разработчиков Пауэрбуилдера придерживается графического составителя программы SQL-выражения, внедренного в интегрированную среду разработки, которая защищает разработчика от разового дизайном синтаксиса и ошибок обозначения{перечисления}. Однако, проект все еще остается уязвимым для даже незначительных{младших} изменений{замен} схемы, которые могут нанести ущерб запросам DataWindow, поскольку запросы не утверждены, пока разработчик не редактирует SQL источник.

Это намного более просто в Девфорс, где мы написали бы:

anOrder. OrderDetails

и ожидайте массив объектов{целей} “OrderDetail”. Если бы нет ни одного, результатом был бы пустой массив. Разработчик не волнуется о том, как OrderDetails найдены или, каковы истинные имена схемы. Кто - то может изменить базу данных, добавлять столбцы, удалять столбцы, переименовывать столбцы, и выражение неизменно. Это “OrderDetail” или “OrderDetails”? intellisense Visual Studio заполняется в деталях автоматически. Если разработчик случайно оставит это “OrderDetail”, то компилятор захватит это во время дизайна. В отличие от справочной информации столбца PowerBuilder DataWindow, которая указана опечатки строки, справочная информация свойства объекта{цели} в Девфорс со строгим контролем типов.

Предположим, что разработчик пишет:

anEmployee. Отдел. Имя

и служащий не имеет отдела. Девфорс возвращает специальный Нулевой{Пустой} объект Отдела со значением по умолчанию для его свойства "Имени", которое отображает соответственно без вмешательства программиста. Поскольку подобный DataWindow сделают запрос в Пауэрбуилдере, если разработчик неосторожно использует объединение equi вместо внешнего объединения, они, возможно, не обратили внимание на проблему вообще начиная со служащих, которые не назначаются отделам, не был бы возвращен вообще!

Эта степень{градус} абстракции и безопасности типа является врожденной модели Девфорс и доступной с первого момента{мгновения}.
В отличие от этого, разработчики Пауэрбуилдера редко создают модели абстракции данных. Код Пауэрбуилдера выставляет{подвергает} детали базы данных непосредственно, потому что это просто проще и быстрее, чтобы сделать так. Но кое-что столь же простой как расчетное значение может вызвать далеко идущие проблемы. Например, предположите, что разработчик хочет отобразить общую сумму элемента{пункта} линии на пользовательском экране. В Пауэрбуилдере мы могли просто использовать SQL-выражение, чтобы вычислить общее количество в запросе DataWindow:

SELECT ordersummary.id, … количество * unitprice как ExtendedPrice FROM orderdetail

-----------------------Страница 6-----------------------

Двигение в .NET от PowerBuilder/6

Вероятно, что это то же самое SQL-выражение будет повторено во многих различных{других} запросах DataWindow всюду по приложению. Даже если бы вычисляемый столбец DataWindow использовался, то же самое выражение DataWindow должно было бы быть повторено. В Девфорс разработчики могут представить общее количество элемента{пункта} линии как заказное свойство класса OrderDetail.

общедоступные Десятичные ExtendedPrice {добираются {возвращают это. Количество * это. UnitPrice;}}

Всякий раз, когда мы обращаемся к свойству ExtendedPrice всюду по приложению, та же самая формула используется. Если бы мы решили позже осуществлять специальную формулу для того, чтобы вычислить, скидки элемента{пункта} линии, основанные на количестве заказывали{упорядочивали}, мы имели бы только одно место, чтобы изменить код. Кроме того мы имели бы полный .NET язык программирования в наличии для того, чтобы разработать любые сложные формулы, вместо частного SQL диалект, внедренный в пределах многократных запросов DataWindow.

Нет SQL?

Есть не SQL, чтобы прервать Девфорс, потому что разработчик почти никогда не пишет SQL. Разработчик или выполняет несколько явных запросов в “языке запросов объекта{цели} со строгим контролем типов” (OQL) или полагается на навигацию объекта{цели} - так называемую "уточняющую запись через точку" - чтобы читать и написать связанным объектам{целям}. Вместо массивных объединений, мы пишем короткие, выразительные операторы, типа anEmployee. Адрес. Государство и anOrderDetail. Продукт. Категория.

Все сведения{интеллект} о связях между таблицами базы данных заключены в капсулу{кратко изложены} в пределах деловых объектов{целей} через ORM. Разработчик не должен знать, являются ли связи дополнительными или не и использовать ли внутренний или внешние объединения. Они просто используют интерфейс, выставленный{подвергнутый} объектами{целями} бизнеса передвигаться, используя уточняющую запись через точку (например.
Заказ{Порядок}. Грузоотправитель), не имея необходимость понимать, как создавать основное SQL.

Почти все SQL-операторы Пауэрбуилдера осуществляют цели, к которым можно обратиться в Девфорс более прямым и простым способом через выражения OQL. Конечно, эти выражения генерируют SQL где-нибудь негласно, где они обработаны очевидно и не отвлекают программиста. Сгенерированный SQL также параметризуется для эффективности и предотвращать SQL нападения инъекции, которые волнуют безопасность сознательные менеджеры IT.

Там может прибыть время, когда мы нуждаемся некоторых в усложненных SQL. Возможно мы нашли горячую точку работы{выполнения}, которую мы не можем покрыть{охватить} сохраненной процедурой. Безотносительно причины{разума}, разработчик Девфорс может написать заказной SQL, чтобы читать от или сохранять к базе данных. Практически, разработчики эксплуатируют эту опцию в очень немногих из операций данных. Когда они делают, они скрывают детали в пределах деловых объектов{целей} непосредственно. Никто не может сказать просто, смотря anOrder. OrderDetails, осуществлено ли это родной навигацией Девфорс или заказное SQL - и это - очень пункт{точка} ORM.

Придерживаясь языка запросов объекта{цели} и точечной навигации, разработчики могут предложить продавцу базы данных нейтральные приложения. Нет никакой потребности изменить код или повторно собрать, чтобы приспособить{разместить} различные{другие} базы данных. Девфорс генерирует специализированный SQL на лету во время выполнения. Инструментальное средство ORM Девфорс в настоящее время поддерживает Microsoft SQL Server, Оракула, DB2 так же как все другие базы данных SQL, которые имеют провайдера OLEDB.

Приложения Пауэрбуилдера могут также остаться справедливо база данных, нейтральная при использовании графического DataWindow, SQL живописец{маляр} или последовательно использующий хорошо сформировал операторы ANSI SQL. Но часто разработчики должны обратиться к продавцу определенные функции и глаголы по причинам работы{выполнения}.

Пожалуйста отметьте, что SQL не трудно учиться или написать. Большинство закаленных разработчиков собрало весь, SQL они будут когда-либо нуждаться и - удобная запись и читение этого. Ориентированный на данные подход Пауэрбуилдера, однако, содержит недостатки{препятствия} в количестве SQL включенного в себя, последствия изменений{замен} схемы, разнообразие similar-but-stilldifferent SQL-выражений, которые должны сделать (почти) ту же самую работу, и полную нехватку изоляции между моделью объекта{цели} и хранилищем данных. Относительный объектом{целью} подход отображения облегчает все такие проблемы{дела}.

-----------------------Страница 7-----------------------

Двигение в .NET от PowerBuilder/7

Настройка Деловых Объектов{Целей}

Из-за управления DataWindow, Пауэрбуилдер не продвигает сильное разделение доступа к данным от UI.
Разработчики Пауэрбуилдера имеют тенденцию определять местонахождение большой части их деловой логики в любом события DataWindow (исключая:
ItemChanged), или SQL делает запрос. Это часто означает, что логика проверки правильности распространена, дублирована, и несовместимо осуществлена всюду по приложению.

PFC не обеспечивает никакой поддержки деловой структуре объекта{цели}. Большинство структур, в которые встроили Пауэрбуилдер, чтобы поддержать разделение модели от представления, отечествено и требует крутой кривой изучения для новых разработчиков из-за их частной природы{характера}. Даже если отдельный сервисный класс используется для проверки правильности, это должно быть "телеграфировано{связано}" в каждое управление DataWindow, где это используется.

w_order.open

// Телеграфировать{Связать} СОБСТВЕННЫЙ ВЕС с, это - сервисный объект{цель} dw_order.of_SetEntity ("n_cst_order")

u_dw.itemchanged
// Передать случай{событие} на обслуживание{службу} проверки правильности долго ll_rc

ll_rc = AncestorReturnValue
IF ll_rc = 0 THEN
IF IsValid (inv_Entity) THEN ll_rc = inv_Entity.event ItemChanged (строка, dwo, данные) END IF
END IF

RETURN ll_rc

n_cst_order.itemchanged
Долго ll_rc

ВЫБЕРИТЕ CASE dwo. Имя
CASE "id"
CASE "employeeid"
CASE "customerid"
CASE "orderdate"
Дата IF (данные) <Сегодня () THEN MessageBox ("Проверка правильности", "дата Заказа{Порядка} не может быть прежде todays дата"), ll_rc = 1
END IF
CASE "requireddate"
Дата IF (данные) <Сегодня () THEN MessageBox ("Проверка правильности", "Необходимая дата не может быть прежде todays дата"), ll_rc = 1
END IF
CASE "shipperid"
CASE "shippeddate"
Дата IF (данные) <Сегодня () THEN MessageBox ("Проверка правильности", "Отправленная дата не может быть прежде todays дата"), ll_rc = 1
END IF
END ВЫБИРАЕТ

RETURN ll_rc

Вышеупомянутое - упрощенный пример, но это демонстрирует два важных пункта{точки}. Сначала, интеграция класса (n_cst_order) обслуживания{службы} проверки правильности явна и подчинена кодированию ошибок разработчиком интерфейса. Во вторых, даже с этим разделением логики проверки правильности, данные не изолированы. Данные, представляющие тот же самый деловой объект{цель}

-----------------------Страница 8-----------------------

Двигение в .NET от PowerBuilder/8

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

Архитектура Девфорс, в отличие от этого, делает естественным поместить деловую логику в деловые объекты{цели}. Это начинается с осуществления{упражнения} ORM, которое генерирует класс для каждого поддержанного базой данных объекта{цели} (исключая: таблица или представление). Поскольку мы обращаемся к данным, вызывая деловое свойство объекта{цели} (anEmployee. LastName, anEmployee. Заказы{распоряжения}), это чувствует себя хорошо, чтобы расширить{продлить} деловой объект{цель} подобным способом, добавляя свойства для других видов государства{состояния} и поведения (anEmployee. Возраст, anEmployee. SalesYearToDate, anEmployee. RaiseMonthlySalary (1000)). Просто сделать. Это обращается.

Картопостроитель Объекта{Цели} Девфорс может обнаружить определенные виды наложенных базой данных критериев проверки правильности (требуемая, максимальная длина строки) и надписать их в сгенерированные свойства для нас. Разработчики могут создать дополнительные собственные правила проверки и применить их и к сгенерированным свойствам и к заказным свойствам.

Фиксируя{Снимая с экрана} деловую логику в деловом уровне объекта{цели}, Девфорс изолирует это от капризов UI, гарантируя, что эта та же самая логика является доступной и прикладной последовательно всем потребителям объекта{цели}, являются ли те потребители окнами, web-страницами, сообщениями, или мобильными устройствами. Большинство разработчиков узнает, что заключение в капсулу{кратко изложение} и доступ к данным и деловая логика в пределах деловых объектов{целей} облегчает возможность создавать большие приложения.

общедоступный статический IEnumerable <Верификатор> GetVerifiers (Возражают pContext) {

Список <Верификатор> верификаторы = новый Список <Верификатор> ();

DateTime mindt = новый DateTime (1900, 1, 1);
DateTime maxdt = DateTime. Теперь;

верификаторы. Добавьте (новый DateTimeRangeVerifier (Дескрипторы. OrderDate, истина, mindt, maxdt)); верификаторы. Добавьте (новый DateTimeRangeVerifier (Дескрипторы. RequiredDate, истина, mindt, maxdt)); верификаторы. Добавьте (новый DateTimeRangeVerifier (Дескрипторы. ShippedDate, истина, mindt, maxdt));}

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

Встроенный механизм верификации в Девфорс предписывает эти правила проверки всюду в нашем приложении.
Передача сообщений о неудавшихся проверках правильности перемещается непосредственно и автоматически к UI (хотя мы являемся бесплатными фиксировать{снимать с экрана}, и переадресовывать ту передачу сообщений, чтобы соответствовать любому виду пользовательского опыта мы нуждаемся.

Сохранение Данных

И Девфорс и Пауэрбуилдер обеспечивают простые и прямые механизмы для того, чтобы сохранить измененные{замененные} данные к базе данных на команде. Оба поддерживают оптимистический параллелизм. И поддержите транзакции с фиксацией и обратной перемоткой.

Большинство приложений имеет тенденцию сохранять все изменения{замены}, сделанные между временем „' и временем „B'. Это - короткая команда и в Девфорс и в Пауэрбуилдере.

Пауэрбуилдер требует некоторой сложности и нескольких тонкости, сохраняя объекты{цели} от многократных таблиц и многократного DataWindows в единственной{отдельной} транзакции. Используя Пауэрбуилдер структура PFC w_master.pfc_save случай{событие} типично управляет сохраняющимся процессом автоматически. Это в свою очередь использует логическое обслуживание{службу} единицы работы PFC (n_cst_luw), чтобы обработать надлежащее обновление поперек объектов{целей} DataWindow, включая выполняющие вставки в главный{высший}/вниз заказ{порядок} и удаляет в заказе{порядке} основания/наверх. Однако, осложнения могут возникнуть, если объекты{цели} DataWindow автоматически не регистрированы в надлежащем заказе{порядке}, таким образом часто явная регистрация объектов{целей} обновления выполнена через

-----------------------Страница 9-----------------------

Двигение в .NET от PowerBuilder/9

of_SetUpdateObjects () метод или pfc_SaveObjects () случай{событие}. Кроме того, когда единственный{отдельный} DataWindow должен обновить многократные таблицы, который является общим{обычным} сценарием с 1:1 дополнительные связи (например внешние объединения), логика должна быть добавлена, чтобы обработать сохранение должным образом. Специально обслуживание{служба} обновления мультитаблицы DataWindow (n_cst_dwsrv_multitable) должно использоваться.

// Вызвать функцию of_Register однажды для каждой таблицы к
// быть обновлен в обновлении мультитаблицы

dw_project.of_SetMultiTable (TRUE)

Натяните ls_projcols [] = {"project_proj_id"}
Натяните ls_taskcols [] = {"task_proj_id", "task_task_id"}

dw_project.inv_multitable.of_Register ("проект", ls_projcols) dw_project.inv_multitable.of_Register ("задача", ls_taskcols)

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

pManager. SaveChanges ();

Девфорс может также обработать распространенные транзакции поперек многократных источников данных. Если бы объект{цель} клиента принадлежал в одной базе данных, и объекты{цели} заказа{порядка} исходили из другой базы данных, и мы сделали изменения{замены} и клиенту и некоторым из ее заказов{распоряжений}, то это то же самое выражение “SaveChanges” сохранило бы клиента и заказало бы изменения{замены} их соответствующим базам данных в единственной{отдельной} транзакции. Ошибка, с которой сталкиваются на одной базе данных заставила бы ROLLBACK выполняться на другом.

Переплет{Связывание} Данных к UI

Получая данные в и из UI управлений - textboxes, полей со списком, и т.п. - может быть самая распространенная, самая утомительная, и наиболее подверженная ошибкам задача развития. Есть огромная выгода к автоматизации процесса в максимально возможной степени.

Пауэрбуилдер обеспечивает такой автоматизированный переплет{связывание} данных из поля с управлением DataWindow. Управления автоматически сгенерированы основанные на источнике данных DataWindow и могут быть легко добавлены, изменены и удалены в пределах живописца{маляра}. Поиск данных и обновление обработаны, автоматически используя возможности механизма DataWindow в комбинации со структурой поддержки (PFC).

Девфорс, вместе с .NET, обеспечивает подобные данные, связывающие механизм. С этим, разработчик заполняет форму UI управлениями и объявляет связи между теми управлениями и свойствами объекта{цели}. Она может сделать так программно, или при использовании одного из визуальных UI проектируют компоненты в ящике для инструментов Visual Studio.

Свойства элемента управления изменены в визуальном редакторе аналогичным способом как живописец{маляр} DataWindow, но с намного более тонким управлением, как управление отдано{предоставлено}. Когда программа выполняется, данные, связывающие механизм сохраняют управления и свойства объекта{цели} в синхронизации. Данные должным образом отформатированы для дисплея в управлениях; пользовательские входы анализируются и утверждены перед отправлением по почте назад к объектам{целям}.

Переплет{Связывание} данных Девфорс хорошо подходит для деловых объектов{целей} и, в частности свойства, которые соответствуют столбцам в таблице базы данных. В отличие от управления DataWindow, данные Девфорс, связывающие работы одинаково{одновременно} хорошо для вложенных свойств (Служащий. Адрес. Государство. StateCode) и заказные деловые свойства объекта{цели} (Служащий. Возраст). Мы можем связать с эфемерными прикладными объектами{целями}, которые не сохраняют государство{состояние} к базе данных (например, список двадцати, последний раз рассматриваемых

-----------------------Страница 10-----------------------

Двигение в .NET от PowerBuilder/10

документы). Мы можем связать с интерфейсом (IAnimal) вместо класса и таким образом отобразить общее{обычное} свойство (Род, Разновидности) гетерогенной и произвольной коллекции объектов{целей} (Слон, Муравей, Змея) привлеченный, возможно, из многократных баз данных (Млекопитающее, Насекомое, Рептилия).

Снова в отличие от DataWindow, в .NET мы можем связать со свойством неданных управления. Например, мы могли связать допускаемое/отключаемое государство{состояние} кнопки “Save” Служащему. CanSave так пользователь может нажать это, только если прикладная логика позволяет текущему пользователю сохранять. Цвет фона текстовых управлений может быть связан заказное свойство, которое указывает, требуется ли соответствующее свойство данных. Хотя много таких свойств могут быть динамически изменены на выражениях использования управлений DataWindow, очень трудно сделать так с процедурным кодом (например метод на NVO).

Хозяин / Деталь

Много Хозяина спорта приложений / Подробные дисплеи, типа заказа{порядка} и его элементов{пунктов} линии, компании и его адресов, и продукта и его признаков. Может быть стимулирующее координировать сетку элементов{пунктов} линии с ее главным заказом{порядком} как пользовательские перемещения от одного заказа{порядка} до следующего. PFC обеспечивает обслуживание{службу} соединения DataWindow, которое автоматизирует большинство этих задач. Один общий{обычный} сценарий интерфейса - то, где главная сетка DataWindow совместно использует набор результата с дочерним{порожденным} свободным форматом DataWindow. Наборы результата обоих, которым хозяин и подробный DataWindow должны соответствовать точно, который может привести к ошибкам{жукам}, потому что их SQL делает запрос, определены отдельно.

Дальнейшие осложнения происходят, когда те же самые данные представлены в многократном DataWindows. Нет никакой автоматической гарантии, которая изменяется в одном месте (скажите, добавление новых элементов{пунктов}), будет отражен в другом (общее количество заказа{порядка}).
Каждый DataWindow имеет его собственный datastore, даже когда ассоциированные обозрения действительно обращаются{относятся} к тому же самому объекту{цели}. Один общий{обычный} сценарий интерфейса - сетка DataWindow на листе, который открывает окно ответа, чтобы изменить существующий отчет{рекорд} или добавить новый отчет{рекорд}. Результаты не могут быть разделены, потому что пользователь может решить поражать "Отмену" после создания изменений{замен} к данным. Вместо этого данные должны быть сохранены к базе данных и затем повторно найдены на сетке DataWindow назад на главном листе, чтобы обновить содержание, ряд дополнительных шагов, которые являются очень неэффективными.

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

Девфорс также поддерживает управление транзакциями в пределах структуры способом, который является подобным тому из управления транзакциями системы управления базой данных. Через вызываемое введение контрольных точек функции, изменения{замены} данных могут быть "откачены назад" к любому произвольному пункту{точке} вовремя. Используя эту функцию позволяет вышеупомянутому типовому сценарию окна ответа быть осуществленным с непринужденностью просто или фиксирование или откатывание назад изменений{замен} данных, когда пользователь выбирает OK или кнопки Cancel в модальном диалоге. Эта функция - существенное преимущество свыше многих других сред, в которых это гарантирует согласованность данных всюду по приложению, все еще обеспечивая способность поддержать вышеупомянутый сценарий. Мало того, что представление данных не повторено, есть также существенное сокращение доступа к базе данных из-за того, чтобы наследовать кэширующий из данных.

Богатые Управления

Девфорс и разработчики Пауэрбуилдера могут создать экраны аналогичным способом способ: красить UI с управлениями и переплетом{связыванием} их к источникам данных. Экран может быть и плотен и разнообразен.

Пауэрбуилдер предлагает богатый набор визуальных управлений через объект{цель} DataWindow из поля. Однако, осложнения могут быстро возникнуть, если врожденные возможности встроенного управления DataWindow не достаточны в удовлетворении визуальным требованиям приложения. Кроме того, в отличие от стандартных пользовательских управлений объекта{цели}, поведение управлений DataWindow не может быть расширено{продлено}. Много бесчисленных часов времени разработчиков были проведены{потрачены}, заставляя управления DataWindow сделать "уловки", чтобы поддержать такие требования как данные управляемые древесные обозрения или графическое представление данных (например диаграммы). Хотя это было успешно сделано во многих приложениях PowerBuilder, получающийся код часто хрупок и труден поддержать, даже для исходного автора!

-----------------------Страница 11-----------------------

Двигение в .NET от PowerBuilder/11

Выборы управления "из поля" в .NET v.2.0 - подобный набор к управлениям DataWindow. But.NET управления сравнительно просты простираться.

Есть огромное число{номер} 3-ьих партийных опций с изобилием мощных, полно-показанных, элегантных управлений. В отличие от управлений Пауэрбуилдера, эти 3-ьи партийные программы могут с готовностью использоваться с любым .NET приложением с тем же самым

врожденный уровень поддержки данным, связывающим как родные управления. Экспресс Разработчика и сетки Infragistics ослепляют примеры, каждая поддержка, мелкомодульная прежде и после событий, вложенных главных/подробных подсеток, группирования, сортировки, подсуммирования, фильтрации, и способности к хосту в пределах ячеек{клеток} сетки широкое разнообразие скалярных управлений (textboxes, datepickers, отобразьте редакторов, и т.д.).

Разработчики могут легко создать их собственные управления, расширяя{продлевая} существующее управление .NET и изменяя его поведения тем же самым способом, стандартный пользовательский объект{цель} может быть расширен{продлен} в Пауэрбуилдере. И разработчики не ограничены "встроенным" управления .NET, поскольку есть бесчисленные богатые 3-ьи партийные доступные библиотеки управления. Не намного тяжелее создать

управление на пустом месте, право вниз на действия, которые тянут{рисуют} и красят это.

Наконец, на горизонте - удивительное графическое богатство Фонда{Основы} Представления Windows. Мы можем возразить, что WPF поставляет больше стиля, чем вещество{сущность}, но стиль продает и, используемый должным образом, может улучшить производительность конечного пользователя.

Девфорс databinding схема облегчит использовать много различных{других} управлений с непротиворечивым API. Девфорс обеспечивает адаптивные "редакторы связей" для 95 % UI типы управления, в которых большинство приложений будет когда-либо нуждаться; эти адаптеры маскируют сложности конфигурации управления так, чтобы прикладные разработчики могли продолжить их UI выполнение, беспрепятственное idiosyncracies продавца управления. Разработчик Девфорс может заполнить конечные{заключительные} 5 % следующими включенными примерами и записью заказных редакторов связей, которые помещаются аккуратно в данных Девфорс, связывающих компоненты. Единственный{отдельный} .NET WinForm мог содержать многократные панели, расщепители, сетки, treeviews и защита свободно рассеянного textboxes, datepickers, окон списка, comboboxes, переключателей, "радио" кнопок, меток, связей{ссылок}, кнопки, диаграммы, отображают …, список является бесконечным.

В пределах Девфорс, весь процесс, от отображения объекта{цели} до databinding, теряет значение в пределах интегрированной среды разработки Visual Studio .NET. Как с Пауэрбуилдером, разработчик никогда не должен оставлять ту среду. UI производительность разработчика в Девфорс сопоставима тому из Пауэрбуилдера, но получающееся приложение обеспечивает, намного более богатый интерфейс испытывают, и позволяет намного большую прикладную масшабируемость с сильным разделением Модели, Рассматривать и Контроллер. Свидетельство{очевидность} этого становится с готовностью очевидным, когда прикладная сложность растет вне простых окон обслуживания СВЕРНУВШЕГОСЯ МОЛОКА к полному, оперяют приложение предприятия. Поскольку прикладная сложность выращивает пребывание усилия по развитию, довольно линейное с Девфорс, но с Пауэрбуилдером, усилие по развитию часто стало экспоненциальным.

Кэширование

Поиск базы данных DataWindow Пауэрбуилдера и обновление чрезвычайно быстры, из-за плотной{напряженной} связи представления и доступа к данным. Это преимущество, тем не менее, является также его крушением, потому что те же самые деловые данные часто скопируются во многие различные{другие} управления DataWindow. Это в свою очередь приводит к тем же самым данным, находимым многократные времена, чтобы гарантировать согласованность поперек многократных визуальных представлений данных. В Девфорс есть только одно представление данных, хранимых в Менеджере Постоянства. Объект{цель} Менеджера Постоянства подобен Пауэрбуилдеру объект{цель} DataStore, в котором это обрабатывает кэширование и государство{состояние} данных. В отличие от объекта{цели} DataStore, тем не менее, Менеджер Постоянства Девфорс также обрабатывает кэширование всех данных, которые являются обязанными к каждому из управлений представления, таким образом избегая дублирования данных в памяти. В Пауэрбуилдере каждое управление DataWindow имеет его собственный кэш данных, который очень увеличивается, сложность развития кода должна была гарантировать согласованность данных.

Типичное приложение DevForce создаст один (или больше) объекты{цели} PersistenceManager на клиенте. Каждый PersistenceManager является и "интеллектуальным" кэшем, и n-ряд возражают полномочию. Каждый деловой объект{цель} отыскивает, или созданный PersistenceManager принадлежит тому менеджеру и постоянно находится в его кэше. Когда объект{цель} найден из базы данных, это находится в кэше. Каждая побочная клиентом операция доступа к данным на том объекте{цели} - каждом запросе, создайте, удалите, отмените, сохраните, и т.д. - обработан его PersistenceManager.

Когда PersistenceManager оценивает выражение “anOrder. OrderDetails”, это смотрит в его кэше для OrderDetails заказа{порядка}. Не находя их, это входит в контакт со средним рядом, Бизнес Девфорс Возражают Серверу, и запрашивает те

-----------------------Страница 12-----------------------

Двигение в .NET от PowerBuilder/12

объекты{цели}. Деловые проблемы{выпуски} Сервера Объекта{Цели} SQL к базе данных, получает результаты запроса, преобразовывает их в деловые объекты{цели} OrderDetail, и передает их назад побочному клиентом Менеджеру Постоянства. Менеджер Постоянства помещает их в кэш, и вперед их к модулю прикладных программ, который спрашивал их. Следующий раз, когда модуль - или любой модуль - спрашивает те OrderDetails, PersistenceManager, поставляет им непосредственно от его кэша.

Этот механизм называется “ленивой иллюстрацией” или “как раз вовремя поиск”. Модуль запрашивающего, и программист, который написал это, являются соответственно забывающими. Разработчик не предпринимает никакого специального усилия получить это поведение. Она знает, что Менеджер Постоянства ответственен за то, что запросил объекты{цели} самым эффективным способом и сделает его работу. Конечно разработчик может вмешаться когда приспособлено. Она может вынудить Менеджера Постоянства сбрасывать на диск кэш, получать специфический отчет{рекорд} из базы данных, даже если это находится в кэше, или только получать отчет{рекорд}, если это находится уже в кэше.

Данные Девфорс, кэширующие значительно уменьшают{сокращают} количество поисков базы данных по сравнению с типичным приложением PowerBuilder подобного размера и сложности. Хотя Пауэрбуилдер поддерживает способность совместно использовать наборы результата, и PFC поддерживает DataWindow, кэширующий обслуживание{службу}, ни один из этих подходов не без шва для разработчика, и ни один не позволяет бессвязные наборы результата. Они типично только используются для того, чтобы кэшировать из статических списков. С кэширующим Девфорс является автоматическим для всех данных и прозрачно разработчику.

Недоступно Операции

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

Приложение может быть структурировано, чтобы запустить, выполниться, завершение, и перезапуск без сетевого подключения в течение расширенного периода. Торговый представитель, летящий на самолете мог делать обзор профиля клиента и хронологии закупки в середине воздуха, сажать, брать новые заказы{распоряжения} в офисе клиента, пойдите в буфет, повторно подключите wirelessly, и повторно синхронизируйте его изменения{замены} с базой данных штаба. Все возможно, потому что Менеджер Постоянства может сделать запрос и обновить его кэш, как будто это была база данных отношения и может сохранить и восстановить его кэшируемое содержание как местный файл. Девфорс поддерживает временное основное ключевое поколение{генерацию} с отсроченной ключевой адресной привязкой, таким образом приложение может создать новые объекты{цели} и сослаться на них в то время как разъединено. Девфорс преобразовывает временные клавиши{ключи} в постоянные клавиши{ключи}, как только подключение вновь установлено.

Архитектура N-ряда

Пауэрбуилдер и Девфорс оба поддерживают способность разработать распространенные приложения. Различие - то, что с Пауэрбуилдером, прикладной архитектурой и развитием является явным; с Девфорс это неявно и прозрачно разработчику.

Хотя Пауэрбуилдер позволяет, что развертывание на различные прикладные серверы, типа .NET и J2EE, развитие этих приложений отчетливо отличается от развития стандартного приложения клиент-сервер. Чтобы разрабатывать распределенное приложение в Пауэрбуилдере, разработчик должен рассмотреть каждую специфическую платформу развертывания, из-за нестандартного{ненормативного} представления наборов результата в пределах каждой среды. Часто это требует, чтобы сложная логика преобразовала в последовательную форму наборы результатов в форму, совместимую с целевой платформой. Наконец, дополнительная сложность возникает, пытаясь поддержать{обслужить} информацию о состоянии данных (например исходные значения), чтобы облегчить надлежащий проверяющий{отмечающий} параллелизм. Проблемы{выпуски} поддержки часто возникают из-за сред развития/развертывания мультипродавца. Нижняя строка - то, что развиваясь действительно распределенный, масштабируемый и ошибка терпимые приложения с Пауэрбуилдером не тривиальны и уклоняются от предмета спора относительно того, является ли это надлежащей платформой для такого развития.

С Девфорс, в отличие от этого, приложения - неотъемлемо multi-tiered, общаясь по стандартным межсетевым протоколам как HTTP и HTTP. Каждое приложение DevForce имеет минимум трех логических рядов: (1) ряд базы данных, (2) средний прикладной ряд сервера, и (3) клиентский ряд. Любой логический ряд может выполниться на любой физической машине.
В автономном режиме (разрабатывая приложение), база данных, клиент, и прикладной сервер - все на том же самом PC. В режиме клиент-сервер, клиент и сервер приложений постоянно находятся на PC в то время как центральные хосты сервера ряд базы данных. Клиент и база данных общаются по внутренней сети.

В режиме n-ряда, PC выполняют клиентский ряд, центральные хосты сервера база данных, и один (или больше) дополнительный хост серверов сервер приложения DevForce.

-----------------------Страница 13-----------------------

Двигение в .NET от PowerBuilder/13

Масшабируемость и Надежность

В режиме клиент-сервер (и с приложениями Пауэрбуилдера), сервер базы данных должен управлять всеми запросами данных от всех клиентов. Каждый клиент запрашивает его собственное подключение к базе данных. Добавление и удаление подключений могут вызвать значимые задержки, очень много клиентских приложений сохраняют подключение открытым для продолжительности пользовательского сеанса. N-ряд развертывание Девфорс разгружает управление клиентскими запросами на отдельный сервер. Тот сервер может объединить ограниченное число{номер} подключений к базе данных и совместно использовать их среди клиентов, которым это служит. Бизнес Девфорс Возражает, что Сервер может добавить серверы как повышения загрузки, используя простой стабилизатор загрузки, чтобы распределить запросы наименее занятому серверу.
Серверы являются не имеющими гражданства и поэтому отказоустойчивыми; конфигурирование стабилизатора загрузки просто. Для некоторых приложений, надежность и непрерывная пригодность{доступность} - основное беспокойство{предприятие}. Разработчики Девфорс могут динамически развернуть многократные прикладные серверы в различных{других} местоположениях, устраняя что специфическая единственная точка сбоя.

Досягаемость

Модель клиент-сервер подразумевает{включает} частную сеть между клиентскими машинами и базой данных. Отдаленные пользователи будут иметь к туннелю в с (VPN) или использовать отдаленную оконечную сервисную программу (например, Citrix), чтобы выполнить приложение. Клиенты Девфорс, в отличие от этого, могут сообщить со “средним рядом” прикладной сервер, используя стандартные межсетевые протоколы.
Такие приложения могут выполниться эффективно{фактически} везде, где они находят подключение, даже по медленному радио или подключению модемной связи, благодаря местному кэшированию и сжатию данных, которые уменьшают{сокращают} сетевой объем перевозок.

Безопасность

Модель клиент-сервер, которой служит Пауэрбуилдер предполагает безопасность частной сети. Каждое приложение - клиент должно иметь его собственное подключение к базе данных и что обычно означает, что строка подключения с паролем базы данных находится на PC. Просто извлечь ту информацию из потерянного или захваченного PC и выставить{подвергнуть} базу данных потенциальным злоумышленникам.

В n-ряде развертывание Девфорс, только прикладной сервер общается к базе данных, таким образом только прикладной сервер хранит{держит} строку подключения. Клиентские PC не говорят с базой данных и не имеют строк подключений. Клиентские PC говорят с прикладным сервером, используя произвольный псевдоним, чтобы обратиться{отнестись} к базе данных, в которой они нуждаются. Сервер приложений будет соблюдать клиентский запрос, только если клиент был заверен, и запрос правилен{допустим}. Девфорс осуществляет и поддерживает разнообразие мер для идентификации, разрешения, и секретности, которые являются вне возможностей{контекста} этого документа.

Конфигурация и Развертывание

В среде Девфорс, разработчики могут решить развертываться в автономном, клиент-сервер, или режим n-ряда, когда и поскольку обстоятельства требуют. Смещение от одной модели до другого может быть столь же простым как изменение{замена} установки во внешнем файле конфигурации. Нет никакой потребности повторно собрать приложение или написать специальную логику, чтобы переключить один режим к следующему.

Интегрированная среда разработки Visual Studio

Одна из самых неотразимых причин двигаться в .NET от Пауэрбуилдера - интегрированная среда разработки Visual Studio. Это обеспечивает чрезвычайно мощную среду разработки, которая является очень расширяемой и включает поддержку обширному списку библиотек третьего лица, управлений и штепселя ins. Intellisense идет далеко вне той из интегрированной среды разработки Пауэрбуилдера и фактически предсказывает завершение кода, основанное на contenxt текущего блока кода. Есть также функции интегрированной среды разработки, как Фрагменты кода и Проектируют Управления Времени, которые дают возможность разработчикам сделать развитие проще для их товарищей по команде. Отладчик также очень мощен, позволяя способность приостановить выполнение, шаг назад, и код изменения{замены}, отлаживая. Инспектор объекта{цели} предусматривает обширную экспертизу и модификацию свойств во время выполнения. Все это составляет в целом более простую кривую изучения для разработчиков большая производительность разработчика.

-----------------------Страница 14-----------------------

Двигение в .NET от PowerBuilder/14

Товары Продукта

Поскольку годы продвигаются, Пауэрбуилдер замечен все больше как устаревшая технология. Посчитать{находить} квалифицированных разработчиков, которые имеют уместный опыт и желание продолжить развиваться в устаревшей среде, быстро становится трудным.
Сканирование любых недавних листингов работы быстро показывает, что немного Пауэрбуилдеров устанавливают относительно количества доступных позиций .NET. Эта тенденция, вероятно, продолжится и вероятно ухудшится, в то время как .NET ресурсы{средства} продолжат расти. Также очень маловероятно, что .NET будет когда-либо становиться "наследством", поскольку Microsoft продолжит продвигать технологию для обозримого будущего.

Итог
Возможность Развития Пауэрбуилдер Девфорс
Доступ к данным Явное использование SQL Прозрачное использование ORM
RAD функциональность Хорошая Польза
UI databinding, Хороший со встроенным управления, Хорошие с любыми управлениями
UI управляет Адекватная Поддержка богатой 3-ьей стороне{партии} управления
MVC поддерживают Трудный осуществить Неявно поддержанный

Постоянство данных, Адекватное с Неявным кэшированием клиент-сервер и n-рядом
образцовая архитектура

Данные, кэширующие Явный, Неявная согласованность данных, согласованность данных
трудный поддерживать{обслуживать} автоматический и быстрый
Развертывание orienteted
Гибкий n-ряд Клиент-сервер неявный дизайн
Слабые Товары Продукта (воспринятый как наследство) Сильный (Microsoft базировал технологию),



Заключение

Прыжок от Пауэрбуилдера к .NET не никакой короткий шаг; однако, использование всестороннего комплекта инструментальных средств, типа Девфорс может помочь закрывать промежуток и выравнивать область{поле}. В итоге, самый важный Пауэрбуилдер Быстрые функции Разработки приложений имеет сопоставимые параллели в .NET / экосистема Девфорс. Девфорс уровень ORM - по крайней мере как удобный и - лучшая модель доступа к данным чем центральный данными подход Пауэрбуилдера. Пауэрбуилдер и Девфорс databinding подобны. Более напряженная интеграция Пауэрбуилдера дает этому преимущество скорости в маленьких приложениях, преимущество, которое рассеивает, поскольку прикладная сложность растет. Пауэрбуилдер UI управляет, достаточны для большинства окон обслуживания, но их бледный по сравнению с 3-ьими партийными управлениями, доступными от

шире сообщество{община} .NET. Кэширующий Девфорс и архитектура n-ряда более силен чем врожденная модель Пауэрбуилдера клиент-сервер.


# # #