LOB (Line of Business) 응용 프로그램 및 현재 개발 관행의 MVVM의 가치

2 년이 지난 지금도 여전히 작업 소프트웨어를 생산하는 실용적인 방법으로 MVVM을 사용하고 있습니다. 어떤 경우에는 훌륭합니다. MVVM 개념이 없었던 작은 조립 라인을 제어하는 ​​다중 스레드 응용 프로그램을 수행했습니다. 물리적 조립 라인의 추상화는 거의 생각할 필요가 없었습니다.

그러나 저의 경력은 주로 비즈니스 운영을 공식화하고 최적화하는 내부 업무용 응용 프로그램을 중심으로 이루어집니다. 이러한 응용 프로그램에는 일반적으로 CRUD 및 복합 작업을 중심으로하는 비즈니스 자료가 있습니다. LOB에서 내 뷰 모델은 비즈니스 클래스 메소드의 한 줄 래퍼 함수의 매우 간단한 모음이되고 결국에는 메시지 상자 표시 또는 창 열기와 같은 가장 간단한 작업을 복잡하게 만듭니다. 사람들이 Window에 대한 "종속성 주입"및 "메시지 공급자"에 대해 오랫동안 설명 할 때 다른 사람이 이상한 것을 찾지 못합니까? winforms에서 매우 간단한 작업에 대한 조언을 요청하는 스택 오버플로에 대한 다른 질문이 몇 개 있습니까?

잘못 이해하지 마십시오-MVVM을 구입하고 축소 포장 및 시판 소프트웨어 패키지의 수평 개발을 수행하는 대규모 팀에게 어떻게 귀중한 방법이 될 수 있습니까? 뷰 모델을 단위 테스트하면 나쁜 RTM 버그를 피함으로써 수백만 달러를 절약 할 수 있으며 전용 UI 개발자는 풍부한 경험을 제공 할 수 있습니다. 그러나 재배치 비용이 최소화되고 비용을 지불해야하는 모든 비즈니스 관리가 간단한 작업 소프트웨어 인 경우, 비즈니스 로직이 이미 단위 테스트 된 상태에서 간단한 "래퍼"VM을 테스트하는 데 왜 시간 단위를 사용해야합니까? 귀여운 애니메이션과 색 구성표를 사용할 수있는 시간이 얼마나됩니까? 하급 개발자가해야 할 일이 있습니까 ( "Save_Click"을 볼 때 사용했던 저장 기능의 버그 추적,

분명히, 나는 WPF의 데이터 바인딩을 정말로 좋아합니다. 이를 활용하기 위해 비즈니스 컨텍스트 및 기타 관찰 가능한 속성에 액세스 할 수있는 창 자체에 데이터 컨텍스트를 설정했습니다. 예, 거의 모든 MVVM "규칙"을 위반합니다. 그러나 최소한 읽기 쉬운 간단한 이벤트 중심 코드가 있으며 새로운 데이터 바인딩 및 유효성 검사를 활용할 수 있습니다. 문제는 디자이너들에게 있습니다. 저는 많이 사용하지 않지만 2012 년에 더 잘 통합되기를 바랍니다. 디자이너는 창과 기본 클래스에있는 수백 가지 속성을 보여줍니다.

관련있는 사람들을 위해, 당신은 저를 자원, 서적, 또는 심지어 이것을 삼키기 쉽게 한 관점의 변화를 가리킬 수 있습니까? 나는 MVVM에 또 다른 기회를 주겠다. 그러나 마지막으로 의존성 주입에 대해 걱정하는 것은 어리석은 일이었다. VM에서 메시지 박스를 보여주기 위해 유닛 테스트를 할 의도는 없었다. 단위 테스트를 수행 한 경우에도 "조밀하게 결합 된"응용 프로그램의 컴파일 시간 오류에 대해 런타임 테스트를 수행하여 더 많은 품질을 얻고 있습니까?

한 가지 대답은 winforms에 머무르는 것입니다. 그러나 WebForms의 마지막 지지자 중 하나 (웹 개발 추세에 대한 비판이 많이 있습니다)로서 Microsoft 인증 트랙에 WebForms가 더 이상 남아 있지 않을 때와 마찬가지로 공룡처럼 느껴졌습니다. 내가 좋아하지 않더라도 앞으로 나아가는 것이 유일한 선택입니다.

저의 관점은 이벤트와 코드 숨김으로 "구식적인 방식"인 Winforms에 대한 수년간의 경험에서 비롯되었습니다. 따라서 가장 간단한 응용 프로그램을 넘어 서면 코드가 빠르게 큰 진흙 덩어리가된다는 것을 확실하게 알 수 있습니다 . 그것은 응용 프로그램이 당시에 쓰여진 방식이기 때문에 불가피했습니다.

Webforms는 상태 비 저장 시스템 (웹)에 대한 상태 저장 추상화의 추가 복잡성을 야기한다는 점을 제외하고는 동일합니다. Rob Conery는 다음과 같이 말합니다.

WebForms는 거짓말입니다. 그것은 기분 전환과 손으로 가득 찬 접시에 제시된 거짓말 소스로 덮인 속임수로 싸여진 추상화입니다. Webforms와 관련이있는 것은 웹과 관련이 없으며 작업을 수행하게합니다.

이것은 dynamicC # 에서 키워드를 사용하고 4 백 줄의 코드만으로 완전히 기능적인 객체 관계형 매퍼를 작성한 사람으로부터 얻은 것 입니다. 그가 권위있게 무언가에 대해 말할 때 나는 듣는다.

현재 작업중 인 응용 프로그램은 Winforms 응용 프로그램이며 기본 양식에 여러 탭이 있습니다. 각 탭에 양식을 동적으로로드 할 수 있습니다. 내가 MVVM이나 MVP를 수행하지 않는 동안 (당신은 같은 라이브러리와 함께 할 수 이 일 ), 나는 적극적으로 절대적으로 양식을 실행하는 데 필요한 해당 코드를 떠나, 내가 밖으로 별도의 어셈블리 수있는 코드의 모든 비트를 밀어 않았다. 거기에는 여전히 수백 줄의 코드가 있으며 폼의 컨트롤 정의, 속성 및 이벤트 처리기 할당을 포함하는 부분 클래스는 계산하지 않지만 폼에 새로운 것을 추가하지 않으면 다시 만질 필요가 없습니다.

폼과 키 / 값 쌍의 컬렉션을 전달할 수있는 정적 메서드가 있는데, 리플렉션을 사용하여 키를 폼의 필드에 자동으로 일치시키고 폼을 컬렉션의 값으로 채 웁니다. 양식의 필드에서 키 / 값 쌍의 컬렉션을 가져 와서 반대로 할 수도 있습니다. 그 모든 것은 약 20 줄의 코드이지만 폼을 사용할 때마다 40 개의 컨트롤에 대해 40 개의 사용자 지정 할당 문을 작성할 필요가 없기 때문에 코드를 사용할 때마다 지불합니다.

해당 키 / 값 목록을 가져 와서 XML로 직렬화하여 파일에 유지할 수 있습니다. 기존 DTO 를 전달하고 해당 필드를 양식에 매핑 할 수있는 다른 양식이 있습니다 . 이 중 어느 것도 Winforms의 "진흙의 큰 공"스타일에서는 실용적이지 않습니다. 적절한 디커플링을 사용하면 거의 사소합니다.

이 소리가 친숙한가요? 그것은해야한다; 본질적으로 가난한 사람의 데이터 바인딩 형식입니다.

분명히, 나는 WPF의 데이터 바인딩을 정말로 좋아합니다. 이를 활용하기 위해 비즈니스 컨텍스트 및 기타 관찰 가능한 속성에 액세스 할 수있는 창 자체에 데이터 컨텍스트를 설정했습니다.

잘 됐네요. MVVM과 호환되지 않아도됩니다. 그러나 MVVM과 같은 패턴은 개발자가 큰 시스템을 구축 할 수 있도록 만들어졌습니다 . 대화 상자 만 표시하면 해당 배관이 모두 필요하지 않을 수 있습니다.

WPF와 같은 시스템의 복잡성의 일부는 특정 문제를 일반적인 방식으로 해결 하려는 모든 프로그래머 라이브러리에 내재되어 있습니다. 이를 위해서는 프로그래머가 라이브러리를 사용할 수있는 모든 실용적인 방법을 고려해야합니다. 이것은 복잡성을 더하지만 라이브러리를 잘 디자인하는 사람들에게는 일관되고 일관된 방식으로 일을한다는 철학을 테이블에 제공합니다.

John Resig의 jQuery 라이브러리를 생각해보십시오. 일관성있는 디자인의 본질이며 DOM 에 대한 많은 이상한 세부 사항 과 브라우저가 처리하는 방식의 변형을 숨 깁니다 . 단지 몇 줄의 자바 스크립트를 작성하는 것이 더 간단합니까? 때때로. 그러나 일관되고 일관된 API로 jQuery 코드를 작성하면 다음 사람이 자신이 한 일을 더 쉽게 이해하고 필요한 경우 해당 코드를 유지 관리 할 수 ​​있습니다.

"큰 응용 프로그램"모델에 대한 나의 실제 경험은 ASP.NET MVC를 사용하는 것입니다. Winforms는 WPF와 마찬가지로 ASP.NET은 ASP.NET MVC에 있습니다. ASP.NET에서 일할 때 항상 그것을 내 의지로 구부 렸습니다. ASP.NET MVC가 구부러집니다. 사용하는 것은 기쁨입니다. 명확하고 체계적인 시스템 구조를 제공하며 응용 프로그램 및 마크 업을 완전히 제어 할 수 있습니다. Javascript, jQuery 및 CSS를 자유롭게 사용할 수 있으며 ASP.NET MVC는 방해가되지 않습니다.

나의 유일한 장애물은 그것에 익숙해졌고 그것 자체의 용어로 그것을 알게되었다.

Rob Conery의 MVC를 배워야 할 추가
자료