2009-05-05 2 views
14

PowerBuilder 10 비즈니스 응용 프로그램을 .NET으로 마이그레이션하는 데 도움이되는 조언이 있습니까?PowerBuilder 응용 프로그램을 .NET에 이식하는 방법

우리 회사는 레거시 PB 응용 프로그램을 .NET (C#)으로 마이그레이션하는 것을 고려하고 있으며 누구나 공유하고 싶은 경험 (좋거나 나쁨)이 있는지 궁금합니다.

응용 프로그램은 10 개의 PBL 라이브러리, 일부 PFC 및 사용자 정의 프레임 워크로 상당히 큽니다. 많은 수의 DLL 호출이 만들어지고 있습니다. 마지막으로 Microsoft SQL Server 데이터베이스를 사용합니다.

"핵심"응용 프로그램 코드를 .NET으로 이식 한 다음 필요에 따라 고급 기능을 이식하는 방법에 대해 설명했습니다.

+0

PB-to-.NET 이전 서비스를 판매하는 영업 사원에게이 스레드에 광고를 게시하거나 직접 연락을 시도하지 마십시오. 나는 당신의 서비스를 구매하는 데 관심이 없습니다. 감사. –

+0

안녕하세요 저스틴 - 여기서 일어나는 일이 궁금합니다. 원래 게시물 이후 잠시 지났습니다. 공유 할 시간이 있다면 듣고 싶습니다. 우리는 PB 11.5 응용 프로그램을보고 있습니다. 우리는 .net으로 마이그레이션하라는 요청을 받았습니다 :) 감사합니다! Bill –

+0

@Bill - 불행하게도, 아무 일도 일어나지 않았습니다. 그 동안 실제로 작업을 전환했지만, 마지막으로 새로운 시스템을 개발하기위한 초기 노력이 있다는 것을 알고 있었지만 PB 마이그레이션을 포함하지 않는 완전히 새로운 엔지니어링 노력이 될 것입니다. 어쨌든 최선을 다해 행운을 빕니다. –

답변

22

나는 제목을 보았을 때, 나는 숨을 쉬고있는 중이었습니다. 유명한 PB 짝이 아니 었습니다. 오 잘. 자신감의 투표에 감사드립니다, 버나드.

나의 첫 번째 제안은 자기기만의 언어를 버리는 것입니다. 내가 "라이트"치즈 케이크의 절반을 먹는다면, 나는 여전히 내 허리띠를 잃을 것이다. 마이그레이션에는 최소 10 분이 소요될 수 있습니다. 무엇을 할 것인가는 을 다시 작성한 것입니다. 시간은 다시 쓰기로 측정해야합니다. 위험은 다시 쓰기로 측정해야합니다. 그리고 디자인 노력은 다시 쓰는 것으로 측정해야합니다.

네, 디자인 작업을 말했습니다. "마이그레이션 (Migrate)"은 펌핑 코드의 이미지를 일부 블랙 박스를 통해 불러내 어 번역 원본을 미러링하여 변환합니다. 1994 년에 만들어진 동일한 디자인 실수를 복제하려고 했습니까? 년 동안와 함께 살았습니까? 우수한 품질의 코드를 사용하더라도 PowerBuilder의 탁월한 디자인 선택이 C#의 엄청난 디자인 선택 일 수 있다고 생각합니다. 직선적 인 전환이 플랫폼의 힘과 강점을 소홀히합니까? 과 함께 15 년 동안 좋은 C# 디자인을 무시한 결과가 있습니까? 당신이 이동에 대한 귀하의 의욕을 언급하지 않기 때문에, 따로 호언 장담


".NET으로는,"당신이 재 작성의 위험을 완화해야 할 수도 있습니다 어떤 옵션을 제시하기 어렵다. 귀하의 경영진이 단순히 PowerBuilder 개발자의 냄새가 좋지 않아 사무실에서 퇴거 당할 필요가 있다고 판단한 경우 다시 작성해 주시기 바랍니다.

단순히 Windows Forms, Web Forms, Assemblies 또는 .NET 웹 서비스를 배포하거나 .NET 라이브러리를 활용하려는 경우 Paul이 말했듯이 11.0 또는 11.5로 이동하면 더 가까이에 작업 할 수 있습니다. 마이그레이션으로. (특히 Web Forms를 사용하여 새로운 플랫폼에 대한 좋은 디자인을 검토하고 다시 작성해 보도록 권하고 싶지만이 노력은 다시 작성하는 것보다 훨씬 작아야합니다.) WPF 응용 프로그램을 배포하려는 경우, 1 년은 기다리는데 꽤 빠르지 만 PowerBuilder 12를 살펴 보는 것은 그만한 가치가있을 것입니다. 올바르게 풀다운 WPF 기능은 PowerBuilder를 독특하고 강력한 위치에 놓을 수 있습니다.

향후 재 작성이 보장되면 (샤워가 저렴할 것으로 예상되는 경우) 변환을 단계적으로 수행 할 수 있습니다. DataWindow.NET을 사용하면 데이터 윈도우를 가져갈 수 있습니다. (이번 주 내 애완 동물 이론은 PowerBuilder 개발자가 내장 된 모든 기능을 재현 할 때까지 PowerBuilder 개발자가 데이터 윈도우를 당연한 것으로 간주한다는 것입니다.) 사전 테스트 된 다중 행의 스크롤 가능한 최소 리소스 사용, 인쇄 가능, 데이터 바인딩 동적 UI, 내장 된 논리 레코드 잠금 및 이벤트에 대한 데이터베이스 오류 변환을 통해 최소한의 SQL을 생성하여 새로운 애플리케이션으로 확장하는 것이 큰 힘이됩니다.

PowerBuilder 코드를 .NET 응용 프로그램에서 사용할 수있는 코드로 변환하여 전환을 단계적으로 수행 할 수도 있습니다. 앞서 언급했듯이 PB 10으로 COM 객체를 생성 할 수 있지만 어셈블리를 생성하려면 11.0 또는 11.5로 이동해야합니다. 이 값은 응용 프로그램이 얼마나 잘 분할되어 있는지에 달려 있습니다. 비즈니스 로직이 비 시각적 객체 (일명 사용자 정의 클래스)로 파티셔닝되는 대신 GUI 이벤트 및 함수를 통해 뱀을 만들면이 값은 의심 스러울 수 있습니다. 여전히, 이것은 faux pas이고 C#으로 완전히 변환되기 전에 수정되어야합니다. 이는 단계적으로 변환 한 후 전체 변환하기위한 예비 단계로서 PowerBuilder 애플리케이션을 유지하면서 수행 할 수있는 작업입니다.

필자는 PowerBuilder에 머물러있는 것을보고 싶습니다. 실패하면, 나는 당신이 성공하는 것을보고 싶습니다.첫 번째 물린 후, you'll have to finish it을 기억하십시오.

행운을 찾는 벨트,

테리.


"핵심 구성 요소"를 시작하려면 .NET으로 이동하는 방법을 언급했습니다. 지금 쯤이면 짐작할 수 있겠지만, 나는 단계적 접근이 현명한 결정이라고 생각합니다. 이제 "핵심"의 정의는 논쟁의 여지가 있지만 반대의 견해는 어떨까요? 생각할 거리? (분명히식이 요법을 시작하는 것은 잘못된 주였습니다.) PB가 현재 어디에 있는지에 따라 애플리케이션 기능 (예 : PB의 미수금, C#의 채무)과 함께 PB와 C#간에 애플리케이션을 나누기가 어려울 수 있습니다. 사업부는 GUI 대 비즈니스 로직입니다. 앞에서 언급했듯이 PB에서 비즈니스 로직을 PB로 추출하여 실행 파일 C#로 가져올 수 있습니다. PB에서 복사 된 데이터 윈도우와 비즈니스 로직이 COM 객체 또는 어셈블리로 펌핑 된 상태에서 C#으로 GUI를 작성하는 방법은 무엇입니까? 다른 방법으로 PB에서 .NET 어셈블리를 사용하려면 11.x로 이동하고 Windows Forms로 마이그레이션하거나 COM callable wrapper에 입력해야합니다.

또는 PowerBuilder에서 C# 개발자를 교육하십시오. 이것은 단지 소문 일지 모르지만 새로운 PowerBuilder 마케팅 태그 라인은 "C# 개발자도 사용할 수 있으므로 간단합니다."라고 들었습니다. ;-)

+1

와우, 자세한 답변 해 주셔서 감사합니다! 우리는 재 작성이 가능한지 여부를 결정하는 초기 단계에 아직도 있습니다. 당신이 옳다고 생각합니다. 궁극적으로 취해진 길이라면, 우리의 응용 프로그램을 다시 쓰는 데 엄청난 노력이 필요할 것이므로,이 일에 대해 솔직해질 필요가 있습니다. .NET으로 옮기기위한 우리의 주된 동기는 데이터웨어 하우스의 장점을 당연하게 여기는 것이 쉽다는 것에 동의하지만, 여기의 개발자는 PB보다 .NET 경험이 훨씬 많다는 것입니다. 어쨌든 통찰력에 다시 한번 감사드립니다. –

+3

뛰어난 게시물 Terry. 그 자리에 서게해서 미안하지만, 내가 한 모든 위대한 일들 PB에 감사하고, 다른 PB 질문에 게시했다는 것을 알았습니다. 그리고 당신의 애완 동물 이론은 이론이 아니라 현실입니다. 거의 모든 사람들이 Java 또는 .Net 용 PB를 할인한다고 얘기합니다. Java와 .Net의 툴을 활용할 수 없지만 PB는 여전히 강력하고 사람들이 아직 얼마나 많은 앱이 실행되고 있는지 인식하지 못합니다. 너무 많은 PB 구현만으로도 그 힘과 유연성을 오용하지 않는다면! –

+0

좋은 답변 Terry. 나는 새로운 기술에 뒤지지 않고 많은 시간을 투자했다. 겸손한 의견이다. PB는 여전히 표준 비즈니스 애플리케이션을 구축하기 위해 최고의 가치를 지니고 있으며, Microsoft는 ASP.NET MVC3와 좋은 객체 저장소 방법을 사용하고있다. 그러나 이것이 OP가 요구 한 것이 아니므로 사과드립니다. PB에서 .NET으로 옮겨가는 것은 결국 재 설계가 될 것이며, 내가 본 대부분의 상점은 워크 플로 기능과 같이 웹에 더 적합한 조각을 분리하는 경향이 있습니다. 마이그레이션하려는 이유를 분명히 자세히 살펴 보는 것은 쉽지 않습니다. –

4

다소 큰 경우 .net (또는 웹 기반 GUI)에서 프런트 엔드를 작성하고 PB 코드와 상호 작용할 때 더 나은 결과를 얻을 수 있습니다. API

PB 9 이상을 사용하는 경우 generate COM or .NET dlls을 사용할 수 있으며 C# GUI로 사용할 수 있습니다. 새로운 언어로 재 작성하는 것 이상으로 이것을 권하고 싶습니다.

다시 작성하는 것이 결코 과장된 것은 아니며 처음 예상했던 것보다 항상 시간이 오래 걸리며 어렵고 버그가 있습니다.

6

나는 gbjbaanb이 위의 좋은 대답을 주었다고 생각합니다. 이 PB10의 응용 프로그램은 새로운 잘 작성 PB10 응용 프로그램

  • 를, 아니면 그것은 하나 PB4에, 점차적으로 수년에 걸쳐 PB10로 변환 1998 년에 만들어졌다 :

    일부 다른 질문 가치가 고려? 잘 작성된 응용 프로그램은 비즈니스 로직과 GUI 사이에서 적절한 구분을 가져야하며 체계적으로 .Net으로 코드를 이식 할 수 있어야합니다. 적어도 이것은 기존 PB 응용 프로그램보다 훨씬 쉬울 것입니다.이 경우 버튼, 데이터 윈도우, 메뉴에 묻혀있는 수많은 논리가 있으며 그 밖의 다른 것을 아는 사람이있을 것입니다. 불가능하지는 않지만 재 작업하기가 더 어렵습니다.

  • 앱이 얼마나 잘 돌아가고 있습니까? 안정적이고 안정적이고 새로운 기능이 많이 필요하지 않은 경우 다시 작성하지 않아도됩니다. 또는 gbjbaanb이 말했듯이 .Net 래퍼를 일부 조각에 넣은 다음 완전히 다시 작성하지 않고도 필요한 기능을 제공 할 수 있습니다. 반면에 앱이 위풍 당하고 불쾌하며 비즈니스 요구 사항이 만족스럽지 않고 사용자를 비효율적으로 만들면 다시 작성하거나 심각한 리팩터링을하고 사례를 개선 할 수 있습니다. PB 친구들이 문장을 제공하고 있습니다. 제 말은, 두 번째 시나리오에서 생계를 꾸려 나가는 것입니다.

소프트웨어가 극단적으로 좋지 않고 회사의 비즈니스에 부정적인 영향을 미치는 경우 재 작성을 반대하지 않지만 점진적인 조정과 개선으로 시스템 발전을 달성하는 데 덜 위험합니다.

또한 Terry Voth가 게시 할 때까지이 스레드에 보석금을 신청하지 마십시오. 그는 StackOverflow에 있으며 최고의 PB 녀석 중 하나입니다.

3

PowerBuilder 11.5 (최근에 릴리스 됨)을 조사하면 상당한 .NET 통합이 추가 될 수 있습니다.

새로운 .NET 코드를 사용하기 위해 PowerBuilder 11.5로 마이그레이션하는 것은 C#에서 전체 앱을 완전히 다시 작성하는 것보다 훨씬 쉽습니다.

3

이 좋은 또는하지만 (상업) 제품 확인하지 않을 경우 나도 몰라 : PB.Net

+0

링크를 제공해 주셔서 감사합니다. 팀의 다른 사람이 실제로 이것을 발견했습니다. 그곳에 대한 더 이상의 정보 나 무료 데모/평가판이 없지만 유망한 것으로 들립니다. –

3

주 내 애완 동물 이론이 될 때까지 당연한 파워 빌더 개발자가 데이터 윈도우를 가지고 있다는 것입니다을 그들은 내장되어 제공하는 모든 기능을 재현해야합니다.

내가 그 이론을 다시 것입니다. 나는 몇 년 전 PB8에서 Java 로의 변환을 시도했지만, 최초의 HTML HTML DataWindow를 사용해도 비참하게 실패했습니다. 현 재 고용주는 현재 제품에서 2K DWO보다 많은데도 불구하고 Datawindow.NET을 사용하지 않고 C#으로 옮겨야합니다. 실현이 시작될 날을 고대하지 않습니다. (전체 제품은 여러 사용자 응용 프로그램, 12 개 이상의 서비스로 구성되어 있으며 약 70 PBD를 사용합니다.)

OP - 응용 프로그램이 비정상적으로 잘 작동하지 않는 한, 구조화 된 (원래 EA 서버용으로 쓰여졌을 수도 있습니다?), 이것은 포트가 아닙니다. 일반 포트가 만족스럽게 작동하려면 PB & .NET 환경에서 상황이 너무 다르게 작동해야합니다. 충분히 강조 할 수는 없습니다. PB 이벤트 모델을 실제로 사용한다면 "포트"가 실패 할 것입니다.

당신은 논리 흐름 (얽혀 UI & 과정), (지금 과정 또는 데이터 를 소유) 제어 흐름, 데이터 액세스 (UI, 데이터 계층, ??)와 DW의 부분을 볼 필요가 코드에서 사용하는 이벤트 모델. 우리가 생각한 것처럼 ASP.NET에 대해 생각하고 있다면, 전체 사용자 상호 작용 경험이 변경되어야하며, 이는 다른 고려 사항으로 되돌아 갈 것입니다.

코드와 직접적인 관련이 없으므로 설치 자동화는 변경 될 예정입니다 (일관된 PB 빌드를 위해 PowerGen을 사용하며 MSBuild는 매우 다릅니다). 설치는 &으로 설정됩니다.

3

큰 응용 프로그램에 대해 이것을 고려하는 사람은 매우 심각하게 DW에 대한 투자를 잃지 않도록 DataWindow.NET 사용을 심각하게 고려하지 않을 것이라고 생각합니다.

3

PHB의 주요 기업은 PowerBuilder가 장난감 언어이며 C#과 같은 새로운 언어로 마이그레이션하는 것이 간단하고 저렴한 비용으로 수행 할 수 있다고 생각합니다. 사실, PB 애플리케이션을 다른 언어로 마이그레이션하는 것은 적어도 새로운 언어로 완전히 새로운 애플리케이션을 개발하는 데 드는 비용이들 것입니다. 최종 앱은 일반적으로 원본에 비해 기능이 손실되어 사용자 만족도가 떨어집니다. 여러 가지 시도를 보았습니다. 어려움과 사용자 문제로 인해 모두 실패했습니다.

파손되지 않은 경우 고치지 마십시오.

관련 문제