저는 커뮤니티에 검토하고 의견을달라고 요청한 특정 아키텍처를 선택했습니다. 나는 문맥을 이해하기 쉽도록하기 위해 더 작은 섹션으로 게시물을 나눈 다음 제안/논평하고있다. 게시물이 길지만 상황을 설명해야하는 것은 유감입니다.Business Objects에서 컬렉션 표현에 대한 아키텍처 선택
내가
응용 프로그램 사용자, 보안 역할이있다 일반적인 비즈니스 애플리케이션
을 구축하고 사업 운영/역할과 증권 등의 여러 비즈니스 모듈 수신, 재고 이전, 판매 주문, 판매 송장에 따라 액션의 권리, 판매 반환, 주식 감사 등등 및 몇몇보고. 이 응용 프로그램은 풍부하고 응답 성이 뛰어난 UI 요구 사항이 많으며 대부분의 경우 연결되지 않은 모드 (로컬 SQL Server 사용)로 작동해야하므로 WinForm 응용 프로그램입니다. 내 응용 프로그램, 예를 들어,의 repetative 요구 사항을 제공 자랑 아무것도하지만, 라이브러리의 단지 세트 - 내가 프레임 워크를 구축했을 무엇
인증, 역할 기반 권한 부여, 데이터 액세스, 유효성 검사, 예외 처리, 로깅, 상태 추적 변경, 프레젠테이션 모델 준수 및 구성 요소 간의 합당한 느슨한 연결이 포함됩니다. CSLA, 프리젠 테이션 모델의 Martin Fowler, 엔터프라이즈 라이브러리의 블록, Unity 등의 개념과 같이 여러 가지를 하나로 통합했다고 말할 수 있습니다. 개발자에게 도움이되는 일련의 라이브러리를 구축하십시오. 기술 요구 사항의 상당 부분을 Google에서 검색하지 않고도 신속하게 생산성을 높일 수 있습니다. 일반적인 프레임 워크를 일반적인 비즈니스 응용 프로그램에서 사용할 수 있도록 유지하고 ASP.NET MVC 환경에서도 동일한 Business Objects를 지원할 수있는 모범 사례를 따르려고했습니다.
내 현재 아키텍처가 내 목표를 잘 수행하고 많은 문제없이 WinForm에서 여러 모듈을 빌드했습니다. 또한이 아키텍처는 단일 코드 줄을 변경하지 않고 동일한 비즈니스 개체 집합을 사용하여 ASP.NET MVC에서 사용할 수있는 프로토 타입을 만드는 데 유용합니다.
내 딜레마
나는 사용자 정의 비즈니스가 나에게 내 솔루션 범위의 문제 범위를 명확하게 OOP 표현을 제공하기 때문에 개체, 나를보다는 데이터와 행동 객체의 컬렉션으로 내 전체 솔루션을 시각화하는 데 도움이 사용하고 있습니다 관계형 데이터 집합 (DataSet) 및 동작 (비즈니스 논리, 유효성 검사) 등을 개별적으로 구현합니다. .NET 2.0에서의 풍부한 데이터 바인딩 지원을 통해 사용자 정의 비즈니스 오브젝트를 UI에 바인딩하는 것이 매우 간편했습니다.
이제 비즈니스 개체를 만드는 동안 비즈니스 개체의 컬렉션 표현에 대한 딜레마가 발생했습니다. 현재 사용자 정의 컬렉션을 구현하기위한 많은 제안을 보았지만 컬렉션을 나타 내기 위해 DataSet을 사용하고 있습니다. 예를 들어, 내 비전에서 일반적인 판매 송장 오브젝트에는 '판매 송장 품목'이 컬렉션으로 포함됩니다. 이제는 이론적으로 각 '판매 송장 품목'이 자신의 데이터 (ItemCode, 이름, 수량, 가격 등)와 함께 자체 동작을 가져야한다는 사실을 인정할 수 있지만 일반적으로 판매 송장의 판매 송장 항목 관리는 판매 송장 객체 자체 (예 : 컬렉션에서 항목 추가/제거. 또한 Sale Invoice 항목 자체에 "Qty가 주문 수량보다 크지 않아야합니다", "Price가 Sale Order의 가격보다 최대 10 % 높아야합니다"등과 같은 Sales Invoice Items에 대한 비즈니스 로직/규칙을 넣을 수 있습니다 .
이런 종류의 비전을 가지고 나는 컬렉션에서 추가/제거 및 컬렉션 항목에 대한 비즈니스 로직을 구현하는 것을 포함하여 대부분의 비즈니스 개체 하위 컬렉션을 부모가 관리 할 수 있다고 느꼈으므로 컬렉션 항목에는 아무 것도 보관되지 않습니다 그러나 데이터.
또한 일반적인 컬렉션은 데이터 바인딩을 지원하는 기능이 모든 컬렉션에서 매우 중요 해지는 그리드의 UI에서 나타납니다. 이 경우 사용자 지정 컬렉션을 구현하면 컬렉션에 대해 강력한 데이터 바인딩 지원도 구현해야합니다. 물론 시간 소모적입니다.
이제 자식 컬렉션 동작이 부모에서 구현되고 자식 컬렉션의 DataBinding이 필요하다는 것을 고려하여 DataSet을 선택하여 비즈니스 개체의 모든 자식 컬렉션을 나타냅니다. 위의 판매 인보이스의 예에서 '판매 인보이스'의 속성은 '인보이스 번호', '날짜', '고객'등이지만 데이터 세트는 'InvoiceItems'입니다. 물론 DataSet을 말하면 바닐라 데이터 집합이 아니라 비즈니스 규칙 유효성 검사를 지원하는 확장 된 DataSet과 DataSet의 행/열에 대한 비즈니스 작업을 자동으로 허용/거부하는 동일한 역할 기반 보안 모델을 자동으로 사용합니다.
이 접근 방식을 사용하면 비즈니스 개체에서 수집 관리 및 데이터 바인딩을보다 쉽게 수행 할 수 있으며 개발자는 모듈을 빠르게 제공 할 수 있습니다.
질문
당신이 방법이 합리적이라고 생각합니까?
이 접근법의 단점이 있습니까?
최근에는 'currentInvoice.InvoiceItems'(DataTable의 경우) 및 'invoiceItem.ProductCode'또는 'invoiceItem'을 쓸 수 있도록 코드에서보다 쉽게 표현하기 위해 'Typed DataSets'를 자식 컬렉션으로 사용하려고합니다. .Dty [ "ProductCode"]. ToString() '또는'(int) drow [ "Qty"] '대신에 .Qty'를 사용하십시오.이 선택 사항에는 단점이 있습니까?
답장을 보내 주셔서 감사합니다.
CSLA에 대해 언급했습니다. 왜 그냥 사용하지 않는거야? 그것은 당신이 언급 한 모든 문제를 해결합니다. – DancesWithBamboo
필자는 CSLA를 합리적으로 조사했지만 CSLA가 너무 많이 일반화하려고 시도한다는 것을 알았습니다. "모바일 객체"개념을 구현합니다. CSLA에 대해 여전히 매우 존중하며, 우리의 경우에 CSLA를 사용하지 않는 이유는 다음과 같습니다 - 1. 새로운 개발자를위한 학습 곡선은 여전히 높습니다. 2. 비즈니스 로직 이식성의 유연성은 복잡성으로 인해 발생합니다. 3. CSLA의 매우 특정한 패턴을 중심으로 전체 아키텍처를 구축하도록합니다. CSLA는 매우 지식 있고 존경받는 사람으로부터 왔지만, CSLA 스킬 셋은 일반적으로 직업 변화 사이에서 이식 할 수 없습니다 !! – Rajarshi