나는 구현하고있는 흐름도가 있으며 사용자 입력 및 일부 처리 결과에 따라 4 ~ 5 개의 경로가 있습니다. 자연스럽게, 나는이 모든 논리를 내 Windows 형식에서 원하지 않는다. 단지 형식의 클래스에 메서드를 호출하기를 원한다. 내 비즈니스 논리 클래스 참조를 System.Windows.Forms에 표시하고 대화 상자 및 메시지 상자를 표시하여 처리하고 결과를 반환하는 데 필요한 입력을 얻으려면 나쁜 디자인입니까?비즈니스 논리 개체에 입력을 요구하는 것은 좋지 않은 디자인입니까?
예, 이것은 잘못된 디자인입니다. 수업은 양식과 의사 소통하고 데이터를 다시 가져올 수있는 수단을 제공해야합니다. 이벤트를 만들고 Form에 가입하여 사용자 정의 EventArgs 클래스의 대화 상자를 만드는 데 필요한 정보를 얻으십시오. 입력을 얻은 후 두 번째 이벤트를 통해 동일한 클래스를 추가 정보와 함께 푸시하면됩니다.
이것은 MVP 패턴과 유사해야합니다.
예, 이것은 좋지 않은 아이디어입니다. 효과적으로 비즈니스 논리를 프레젠테이션과 매우 밀접하게 결합하고 있습니다. 다른 상황에서 쉽게 비즈니스 로직을 재사용 할 수 있으며 비즈니스 로직을 건드리지 않고도 UI를 대체 할 수는 없습니다.
UI 및 비즈니스 로직 레이어가 통신하고 UI 레이어가 UI를 처리하도록해야합니다.
나쁜 디자인이라고 생각합니다. 응용 프로그램의 구성 요소를 분리 할 때는 다른 컴퓨터에서 실행할 수 있도록 충분히 분리시켜야합니다.
예. 왜냐하면 당신의 busienss 객체가 단순히 비즈니스 객체가 아니라는 것을 의미하기 때문입니다.
MVVM 패턴을 사용하고 로직을 viewmodel에 넣습니다.
정확하게 사용 된 정확한 패턴이 잘 검사 된 패턴을 사용하는 것보다 덜 중요하다고 생각하지만 MVC가 WinForms에 더 적합 할 것으로 판단됩니다. –
이벤트 기반 MVP 패턴도 옵션이라고 생각합니다. 이 뷰는 이벤트를 발생시키고 발표자는 마법적이고 신비한 방식으로 이벤트를 처리합니다. – nick
UI 나 UI가 전혀없는 상황 (예 : 서버 또는 일괄 처리)에서 비즈니스 로직을 실행해야 할 수 있으므로 좋지 않은 디자인입니다. 이것이 비즈니스 로직과 UI의 분리입니다. 가능한 경우 UI 클래스에서 모든 필요한 사용자 입력을 먼저 얻은 다음 비즈니스 논리에 따라 작업을 전달하는 것이 좋습니다. 그러나 비즈니스 로직 프롬프트에서 더 많은 정보를 얻으려면 비즈니스 로직 API가 콜백 메소드 델리게이트를 사용하는 것이 더 좋습니다.이 콜백 메소드 델리게이트는 추가 입력을 요청하기 위해 호출 할 수 있습니다. 그런 다음 UI 레이어가 사용자에게 요청하는 최선의 방법을 결정할 수 있습니다.
MVP 패턴 나는 믿습니다. – nick
이것은 무엇을 해야할지에 대한 나의 첫 번째 성향이었습니다. 나는 그것을 검증 할 사람을 찾고있는 것 같아. 감사. – Keith
네, 그게 사실이어야합니다. 그러나 예제가 더 적합하다고 생각합니다. – Femaref