클래스의 도메인 논리를 도메인 계층의 개체의 책임과 분리하는 방법이 있는지 궁금합니다.도메인 및 ui 레이어 분리 합성
예 :
// Domain classes
interface MachinePart
{
CalculateX(in, out)
// Where do we put these:
// Draw(Screen) ??
// ShowProperties(View) ??
// ...
}
class Assembly : MachinePart
{
CalculateX(in, out)
subParts
}
class Pipe : MachinePart
{
CalculateX(in, out)
length, diamater...
}
많은 기계 부품 조립 기계 값 X를 계산하는 응용 프로그램이 있습니다. 어셈블리는 파일 표현에서로드되고 합성으로 설계됩니다. 각 구체적인 파트 클래스는 전체 어셈블리의 동작을 시뮬레이트하기 위해 CalculateX(in,out) 메서드를 구현하는 일부 데이터를 저장합니다. 응용 프로그램은 잘 실행되지만 GUI는 없습니다. 유용성을 높이기 위해 기존 구현 위에 GUi를 개발해야합니다 (기존 코드의 변경은 허용됩니다). GUI는 어셈블리의 도식적 인 그래픽 표현을 보여 주어야하며 여러 매개 변수를 편집하기위한 특정 대화 상자를 제공해야합니다.
이러한 목표를 달성하려면 응용 프로그램에서 각 기계 부품이 화면에 스키 매틱 표현을 그리고 속성 대화 상자와 기계 시뮬레이션 영역과 관련이없는 다른 사항을 표시하는 새로운 기능이 필요합니다. 각 부분에 대해 Draw(Screen) 기능을 구현하는 몇 가지 솔루션을 생각할 수는 있지만 각 요소에 만족스럽지 않습니다.
처음에 MachinePart 인터페이스에 Draw(Screen) 메소드를 추가 할 수 있지만 도메인 코드가 ui 코드와 섞여서 각 기계 부품 클래스에 많은 기능을 추가하여 도메인 모델을 읽기 어렵게 만들었습니다 이해하다.
"단순한"해결책은 모든 파트를 방문 가능하게 만들고 방문자에게 ui 코드를 구현하는 것이지만 방문자는 내가 좋아하는 패턴에 속하지 않습니다.
UI 구현을 추가하기 위해 각 기계 부품 클래스에서 UI 변형을 파생시킬 수 있지만 각 부품 클래스가 상속에 적합한 지 확인해야하고 기본 클래스의 변경에주의해야했습니다.
현재 가장 좋아하는 디자인은 각각의 구성 요소가 기계 부품을 정의하기 위해 데이터를 저장하고, UI 메소드에 대한 구현과 해당 도메인 클래스의 인스턴스를 생성하는 팩토리 메소드가있는 병렬 복합 계층을 작성하여 "변환 "도메인 어셈블리에 대한 UI 어셈블리. 그러나 생성 된 도메인 계층 구조에서 UI 계층 구조로 돌아가서 예를 들어 도면에 계산 결과를 표시하는 데 문제가 있습니다 (일부 부품은 시뮬레이션 후 스키 매틱 표현에 표시하려는 계산 중 일부 값을 저장한다고 가정).
그런 문제에 대한 입증 된 패턴이있을 수 있습니까?
나는 많은 MVC, MVP, MVXYZ, 수동보기 ... 기사 및 모두 내가 Ui 코드와는 별도로 busines 논리를 분리하라고 지시하지만 실세계 예제에서는 분리를 수행하는 방법이 아닙니다. 모든 gui 프로젝트의 가이드 라인을 따르지만'DrawText (mymodel.GiveMeText) '만큼 간단하지는 않지만 문제가 발생합니다. mvvm은 ms 특정 패턴 인 것 같습니다 (이것은 .NET 프로젝트가 아닙니다). 매우 기술적 인 C#/WPF 기사 만 찾을 수 있습니다. 좀 더 일반적인 패턴이 필요해. – hansmaad
MVVM은 MS .net 컨텍스트에서 많이 논의되지만 완전히 "MS 특정"은 아닙니다. Java에서 MVVM은 [link 1] 전에 SO에서 토론되었습니다 (http://stackoverflow.com/questions/2984828/is-there-anything-similar-to-wpf-and-mvvm-in-java-world). [링크 2] (http://stackoverflow.com/questions/2105121/what-to-use-mvc-mvp-or-mvvm-or) – Marijn