복수의 Task를 수행하는 단일 프로그램 생성에 대해 문의드립니다.

🖥️ UI/UX 프로그래밍 Q&A WPF Q&A
#1

두 달 전만 해도 WPF에 대해 아는 것도 없었는데, 업무 시간 외 틈틈히 공부하면서 궁금하거나 구현하고 싶은 것들을 구현하면서 많이 배웠던 것 같습니다. (살아있다는 것을 다시 한번 느끼게 됩니다. ㅎㅎ)정말 이곳 .NET Dev를 통해서 조언 주셨던 분들께 다시 한번 감사드립니다.

패키징 관련해서 궁금한 내용이 하나 있습니다. 제가 구상적인 부분을 우선 설명드리면 아래와 같습니다.

  • 서로 다른 Task를 수행하는 프로젝트/페이지들이 있다.
  • 각 Task를 trigger하는 request가 존재하며, 각각의 프로젝트/페이지를 호출한다.
  • 서로 다른 Task를 수행하는 프로젝트/페이지는 반드시 하나의 프로그램 혹은 하나의 설치 프로그램으로 설치 되어야 한다.

20220426_205045
20220426_2050451102×971 96.4 KB

현재로선 구현되면 좋겠다는 구상 정도인데, 가능한 지, 가능하다면 어떻게 구현해야 할지 조언을 얻고 싶습니다.

방법1 경우에는 다음과 같은 방법으로 생각하고 있습니다.

  1. WPF로 각각의 Task를 구현한 프로그램을 각각 만든다.
  2. Installer를 통해서 해당 프로그램들을 하나의 설치 파일을 만든다.
  3. Trigger()에서 특정 프로그램을 실행하도록 한다.
    → 이곳에서 고민이 되는 부분은 2번과 3번입니다. 관련 경험이 있으신 분이 계신다면 조언을 부탁드립니다.

방법2 경우에는 현재 다음과 같은 방법으로 생각하고 있습니다.

  1. 프로젝트 기본 실행시에는 특정 페이지로 이동하지 않는 MainWindow()로 이동한다.
  2. 각 Task를 구현한 Page를 별도로 만들고 이를 Navigation을 적용시킨다.
  3. Trigger()에서 프로그램 실행 및 관련 Task()에 해당하는 페이지로 랜딩되도록 한다.
    → 문제는 3번인데요, 기 설치된 프로그램을 실행과 함께 navigation을 적용하는 방법을 적용해보신 분이 계신가요?

읽어주셔서 감사합니다.

좋아요 2
#2

먼저 질문에 대한 제 나름의 답을 드리기 이전에

왜 이런 구조가 필요한지를 설명 듣고 싶은데 가능할까요?

좋아요 2
#3

관심 갖아주셔서 감사드립니다. (dimohy님 항상 감사드립니다! )

저는 일전에 ASP.NET를 사용하다가, 손을 떼고 웹 개발, 주로 Front-End를 참여하였습니다. 그러다 회사에서 기존에 고객사 별로 커스텀된 오래된 WinForm들을 통합하라는 미션을 제게 주었습니다. (회사 입장에선 .NET이면 물불 안 가리고 같은 걸로 보이나 봅니다. ㅎㅎ)

허허허… 막연한 마음에 어떻게 해야 할지 고민고민을 하다가 (Desktop app이어야 한다는 전제 조건이 있어서 ) WinForm보단 WPF로 배우면서 구현해봐야겠다고 생각이 들어서 혼자서 이렇게 가지고 놀면서 배우고 있습니다. 결국 고객사별도로 커스텀된 사항이 있고 각기 수행하는 Task도 달라서 각기 만들기 보다 하나의 프로그램에서 호출되는 방법이 다르면 좋을 거 같아서 생각하게 되었습니다.

좋아요 1
#4

네…

일단, 궁금하시는 내용은 제가 다른 일로 저녁 즈음에 집중에서 살펴본 뒤 답해드릴 수 있을 것 같고요,

업무의 테스크 (또는 페이지, 정확한 개념 단위는 이후에 여쭤볼께요) 를 dll 단위로 컴파일 한 후 웹 URI로 접근할 수 있도록 하고, dll을 읽어와서 동적으로 어셈블리를 로딩한 뒤 화면에 표현할 수 있습니다. 이러면 사이트에 따라 다르겠지만 배포도 편해지고 설치방식도 복잡하지 않게 될 것 같네요.

좋아요 3
#5

말씀 감사드립니다. 아직은 말씀하시는 내용이 제겐 어렵게 느껴지지만, 의견 주시면 하나씩 공부하겠습니다.

좋아요 1
#6

  1. 방법1
    프로그램의 일체감, 그러니까 A → B 프로그램을 호출할 때 동일 프로그램의 느낌으로 구성하기가 좀 힘들겠죠. 그리고 요청의 범위에 따라서 프로세스로 요청하는 방법에 대한 어려움이 있을 수 있습니다. A, B 프로그램 끼리 상호작용이 적을 경우 이 방식을 택할 수도 있겠습니다만,
    기존 애플리케이션을 유지하면서 통합하려는 방법의 일환으로 통합의 과정에서 사용할 수 있겠습니다.

  2. 방법2
    기 설치된 프로그램을 내부로 통합하기는 힘들거나 불가능 합니다. 이런 경우 방법1을 사용하여야 하고요, 새로 배포하는 경우 방법2로 계속해서 통합할 수 있습니다.

관련해서 댓글로 드린 내용을 점진적으로 적용해보는것도 좋습니다. 이 방법은 기존 설치된 프로그램을 통합하는 방식은 아니고
배포의 용이성과 커스터마이징의 용이성의 장점이 있습니다. 필요한 DLL을 동적으로 읽어서 하나의 프로그램처럼 동작하게 할 수 있거든요.

프로젝트 A → A 프로젝트 DLL
프로젝트 B → B 프로젝트 DLL
프로젝트 C → C 프로젝트 DLL

메인페이지에서 A사의 설정이 있는 사람은(또는 설치에 의해 그러한 설정이 있을 경우) A 프로젝트 DLL을 동적으로 읽어서 화면을 구성합니다. A → B 요청의 경우 요청시 B 프로젝트 DLL을 동적으로 읽어서 페이지로 로딩하고 관련 요청 정보를 전달하여 구동하도록 합니다.

※ 여기서 DLL들은 웹서버에 미리 올려놔서 원격으로 읽어올 수 있게 구성하고, 그 위치에 배포하는 식이죠.

좋아요 2
#7

말씀 감사합니다. 아직은 개념적으로 어렵게 다가오는 부분이 있어서 관련 자료를 더 찾아봐야 할 것 같아요. 관련 자료가 정리 되는대로 저도 이곳에서 공유드리겠습니다.

참! 기존 어플리케이션을 리팩토링하면서 WPF로 새롭게 만들어야 하기 때문에 방법2에서 말씀하신 내용으로 접근을 한다면, 이 경우 Trigger로 각각의 페이지로 랜딩하는 방법은 있을까요?

예를 들어 다음과 같이 실행하도록 가능할까요?

  • 버튼1을 누르면 어플리케이션 실행과 동시에 페이지A로 이동
  • 버튼2를 누르면 어플리케이션 실행과 동시에 페이지B로 이동
좋아요 1