두 달 전만 해도 WPF에 대해 아는 것도 없었는데, 업무 시간 외 틈틈히 공부하면서 궁금하거나 구현하고 싶은 것들을 구현하면서 많이 배웠던 것 같습니다. (살아있다는 것을 다시 한번 느끼게 됩니다. ㅎㅎ)정말 이곳 .NET Dev를 통해서 조언 주셨던 분들께 다시 한번 감사드립니다.
패키징 관련해서 궁금한 내용이 하나 있습니다. 제가 구상적인 부분을 우선 설명드리면 아래와 같습니다.
서로 다른 Task를 수행하는 프로젝트/페이지들이 있다.
각 Task를 trigger하는 request가 존재하며, 각각의 프로젝트/페이지를 호출한다.
서로 다른 Task를 수행하는 프로젝트/페이지는 반드시 하나의 프로그램 혹은 하나의 설치 프로그램으로 설치 되어야 한다.
저는 일전에 ASP.NET를 사용하다가, 손을 떼고 웹 개발, 주로 Front-End를 참여하였습니다. 그러다 회사에서 기존에 고객사 별로 커스텀된 오래된 WinForm들을 통합하라는 미션을 제게 주었습니다. (회사 입장에선 .NET이면 물불 안 가리고 같은 걸로 보이나 봅니다. ㅎㅎ)
허허허… 막연한 마음에 어떻게 해야 할지 고민고민을 하다가 (Desktop app이어야 한다는 전제 조건이 있어서 ) WinForm보단 WPF로 배우면서 구현해봐야겠다고 생각이 들어서 혼자서 이렇게 가지고 놀면서 배우고 있습니다. 결국 고객사별도로 커스텀된 사항이 있고 각기 수행하는 Task도 달라서 각기 만들기 보다 하나의 프로그램에서 호출되는 방법이 다르면 좋을 거 같아서 생각하게 되었습니다.
일단, 궁금하시는 내용은 제가 다른 일로 저녁 즈음에 집중에서 살펴본 뒤 답해드릴 수 있을 것 같고요,
업무의 테스크 (또는 페이지, 정확한 개념 단위는 이후에 여쭤볼께요) 를 dll 단위로 컴파일 한 후 웹 URI로 접근할 수 있도록 하고, dll을 읽어와서 동적으로 어셈블리를 로딩한 뒤 화면에 표현할 수 있습니다. 이러면 사이트에 따라 다르겠지만 배포도 편해지고 설치방식도 복잡하지 않게 될 것 같네요.
방법1
프로그램의 일체감, 그러니까 A → B 프로그램을 호출할 때 동일 프로그램의 느낌으로 구성하기가 좀 힘들겠죠. 그리고 요청의 범위에 따라서 프로세스로 요청하는 방법에 대한 어려움이 있을 수 있습니다. A, B 프로그램 끼리 상호작용이 적을 경우 이 방식을 택할 수도 있겠습니다만,
기존 애플리케이션을 유지하면서 통합하려는 방법의 일환으로 통합의 과정에서 사용할 수 있겠습니다.
방법2
기 설치된 프로그램을 내부로 통합하기는 힘들거나 불가능 합니다. 이런 경우 방법1을 사용하여야 하고요, 새로 배포하는 경우 방법2로 계속해서 통합할 수 있습니다.
관련해서 댓글로 드린 내용을 점진적으로 적용해보는것도 좋습니다. 이 방법은 기존 설치된 프로그램을 통합하는 방식은 아니고
배포의 용이성과 커스터마이징의 용이성의 장점이 있습니다. 필요한 DLL을 동적으로 읽어서 하나의 프로그램처럼 동작하게 할 수 있거든요.
프로젝트 A → A 프로젝트 DLL
프로젝트 B → B 프로젝트 DLL
프로젝트 C → C 프로젝트 DLL
메인페이지에서 A사의 설정이 있는 사람은(또는 설치에 의해 그러한 설정이 있을 경우) A 프로젝트 DLL을 동적으로 읽어서 화면을 구성합니다. A → B 요청의 경우 요청시 B 프로젝트 DLL을 동적으로 읽어서 페이지로 로딩하고 관련 요청 정보를 전달하여 구동하도록 합니다.
※ 여기서 DLL들은 웹서버에 미리 올려놔서 원격으로 읽어올 수 있게 구성하고, 그 위치에 배포하는 식이죠.
