안녕하세요. 항상 눈팅만 하다가 궁금한 점이 있어 처음으로 질문글을 남깁니다.
현재 회사에서는 WinForms + .NET Framework 4.7.2 기반으로 구성된 내부 프로그램을 사용 중입니다.
개발 환경은 DevExpress와 함께 Visual Studio/Dev 기반이고, 사내 개발자분들도 모두 .NET 기반에 익숙한 상태입니다.
최근에는 해당 프로그램을 웹 기반으로 점진적으로 전환하려는 논의가 진행 중이고,
우선은 첫 단계로 기존 프로그램에서 대시보드 화면만 웹으로 분리하여 띄워보는 방향으로 내부 검토 중입니다.
현재 생각 중인 구조입니다.
- 기존 프로그램은 유지 (WinForms + .NET Framework 4.7.2)
- 대시보드는 ASP.NET Core 기반 웹서버에서 개발
- 기존 WinForms 프로그램 내에서 WebView2 등의 컨트롤로 웹 대시보드 띄움
- 향후 웹 전체 전환을 고려하되, 우선 대시보드만 분리된 구조로 시도
사용 중인 기술 스택 및 고려 사항
- 현재 DevExpress를 사용 중이며, 웹 전환 시에도 DevExpress 또는 동등한 수준의 컴포넌트를 고려 중입니다
- 특히 중요한 기능으로는:
- 웹 상에서 Excel 및 Word와 유사한 UI 제공
- 실질적인 엑셀/워드 문서 읽기 및 작성
- PDF 변환 및 출력 기능 필수
- 현재 제가 생각하는 방법은 Blazor인데,
내부 개발자분들이 C# 기반에 익숙하셔서 다른 개발자 분들도 보다 쉽게 배울꺼같습니다.
- 웹서버는 Kestrel 또는 IIS 기반으로 운영 예정이며,
- 일부 PC에 로컬 실행하거나 내부망 서버에 배포하는 방식으로 구성하려고 합니다
mydashboard.exe처럼 Blazor 앱을 로컬에서 실행하고, WebView로 http://localhost:5000 접근하는 구조도 검토 중입니다
궁금한 점 / 조언 요청
- 위와 같은 구조 (기존 WinForms에서 WebView로 웹 대시보드 띄우기)를 실무에서 적용하신 분 계신가요?
- Blazor를 선택하는 것이 현실적인지, 아니면 React/Vue + API 등 다른 방식이 더 나은 선택일지 실무 경험이 궁금합니다
- Blazor에서 구조를 MVC처럼 View / Service / Model로 나눠서 사용하는 방식이 일반적인지도 궁금합니다
- DevExpress 기반 문서 기능 (엑셀/워드/PDF)을 웹에서 유사하게 구현하려면 어떤 컨트롤이나 방식이 괜찮을지 조언 부탁드립니다
- Kestrel 또는 IIS로 Blazor 앱을 배포할 때 성능/보안/관리 측면에서 주의할 점이 있을까요?
Blazor는 개인적으로는 학습 중이지만 실무에서는 처음 접하게 되어 이렇게 질문드립니다.
유사한 경험 있으신 분들의 피드백이나 조언을 정말 감사히 받겠습니다.
긴 글 읽어주셔서 감사합니다.
3개의 좋아요
점진적 마이그레이션인 경우에 적절한 방법인 것 같습니다.
해보지는 않았지만 문제가 예상되지는 않습니다.
현재 인력들의 기술 스택을 고려한다면 블레이저가 맞습니다.
새로운 인력의 유입 가능성이 있다면 인력 수급이 용이한 다른 스택을 고려하는 게 맞을 수도 있으나, 한 팀에 여러 스택이 공존할 때 들어가는 비용도 만만치 않습니다.
블레이저는 요소의 재사용성을 최고의 미덕으로 칩니다.
즉, UI요소를 가급적 잘개 쪼개는 방식에 적합한데, 이 경우, 뷰모델 등의 역할을 요소가 하기에 특이한 설계 패턴이 필요하지 않습니다.
그리고, 서비스는 다른 프로세스와의 협업을 담당하기에, 어떤 디자인 패턴에서도 별도로 구분되어야 합니다. 다만, 윈폼에서 사용하던 서비스는 모던 닷넷으로 마이그레이션이 필요할 것입니다.
반드시 office-like 해야 한다면, 자체 개발 보다는, 블레이저를 지원하는 외부 프레임워크(Telerik 이나 Syncfusion)를 사용하는 것이 효율적입니다.
그런데, 브라우저 환경에서 윈폼과 같은 네이티브 렌더링의 속도를 맞추는 게 달성하기 힘든 목표일 수도 있습니다. 이는 브라우저 환경에 맞는 UI 디자인을 새로 도입하는 게 더 나을 수도 있다는 의미입니다.
특이한 주의점은 없습니다.
웹 환경은 사용자 접근성이 좋고, 배포 시에도 보다 간단하다는 장점이 있습니다.
마지막으로 윈폼(4.7.2)의 웹 전환은 모던 닷넷으로 마이그레이션을 수반할 수도 있고, 웹 환경이라 윈도우 네이티브 API를 호출하지 못할 수도 있다는 점을 고려하시는 게 좋을 것 같습니다.
3개의 좋아요
답변감사합니다!!
윈도우 api관련 부분만 확인해보면 되겠네요 ㅎㅎ.. 아마 윈도우 api를 사용하는 부분이 없어서 대체가능할꺼같지만 언제 어디서 사용중인지 모르니..ㅠㅠ 차근차근 진행시켜봐야겠네요
다시한번 답변 감사합니다!!
4개의 좋아요
하나 빼먹은 게 있네요. 가능하다면 리눅스에 배포하는 게 경제적이고 성능이 더 좋습니다.
2개의 좋아요
닷넷5 시절의 경험이긴 한데, 저는 인수인계받은 레거시 윈폼 프로젝트를 블레이저로 성공적으로 마이그레이션해서 유지보수한 경험이 있고, 그 과정의 큰 줄기는 아래와 같습니다
1. 수동 혹은 업그레이드 도우미등을 사용해 닷넷프레임워크 프로젝트를 닷넷(코어) 프로젝트로 마이그레이션
- 크게 바뀌는 영역은 SDK스타일로 바뀐 csporj 파일 등 msbuild 영역이고 소스코드나 라이브러리 의존성 등은 거의 유지되고 호환되던걸로 기억합니다.
- 닷넷코어로 빌드한 윈폼은 더이상
mono(리눅스) 에서 실행할 수 없게 됩니다. 윈폼을 아예 제거하려는 입장에서는 아무렴 괜찮았습니다.
2. 프로젝트를 분리하고 연동하는 등의 구상없이, 그냥 하나의 프로젝트에서 윈폼과 블레이저 서버를 둘다 가동시킵니다.
- 이시점에서는 하나의 프로세스에서 기존 윈도우 데스크톱 애플리케이션 동작과 웹서버(블레이저서버) 동작이 동시에 이뤄지게 됩니다.
STAThread 같은 문제로 동작성능 등 일부 불만족이 생길수도 있습니다.
- 과도기적인 상태인 와중에도 통합된 사용자경험을 제공하고자 한다면, 기존에 고려하시던
WebView2 혹은 이런 템플릿같이 블레이저 하이브리드를 적용해볼 수 있습니다.
3. 윈폼으로 출력하던 사항을 .razor 로 작성된 블레이저 페이지로 점진적으로 전환하면서 종래에 윈폼 의존성을 완전히 제거해 냅니다.
- 이 방법은 과정의 어느 순간에도 프로젝트의 규모나 복잡성이 크게 비대해지지않고 실행/배포가능한 상태를 유지하며, 끊김이 없이 가역적인 커밋 히스토리를 그립니다. 너무 만족스러운 경험이었습니다.
TMI
- XAML을 재활용하는 느낌으로 윈폼소스코드를 최대한 재사용하는 게으른 방법을 찾아보았으나 실패하여 그냥 폼마다 페이지로 새로 만들었습니다.
- 98.css 같은걸 써먹으면 기존 윈폼화면을 참고해 흉내내기에 좋았습니다.
4. 마이그레이션 이후의 고려사항
- 위 과정을 따르고 나면 프로젝트 자체는 완전히 웹서버(블레이저 서버) 로 전환되었으나, 배포형태는 여전히 사용자PC에서 Kestrel로 셀프가동되는 형태로 남아있을것입니다.
- 이상태에서 아예 Photino 등을 적용해 기술만 웹기술인 모던 데스크톱 애플리케이션이될지,
- 아니면 실질적인 웹으로써 운영하고자 기존에 로컬 실행을 상정하고 작성된 코드와 기획을 어떻게 잘 바꿀지는, 모든것이 현대화된 이때에 와서 느긋이 고민해보시면 되겠습니다.
4개의 좋아요
조언 감사합니다!! 많은 도움이 됐습니다!! 아직 시작단계지만 차근차근하면 언젠가는 끝나겠죠… 정말 조언 감사합니다!!