3 레이어 디자인과의 혼동

Question

3 레이어 디자인 웹에서 예제를 검토했으며 대부분의 샘플이 데이터 세트 또는 데이터 테이블 중 하나를 반환한다는 것을 알았습니다. 저를 혼란스럽게하는 것은 유형리스트를 기반으로하는 유형 내에서 속성이나 메소드를 사용할 수 있도록 일반 유형의 목록을 반환하려는 경우입니다. 데이터에 따라 특정 방식으로 다양한 필드를 연결하는 Name 속성을 사용하는 예제로서 List가 폼의 컨트롤에 바인딩되어 있으면 Name 속성을 데이터 필드로 사용할 수 있습니다. 데이터 셋이나 테이블을 사용할 때 똑같은 일을 원한다면 데이터베이스 나 데이터 테이블을 사용하지 않기 위해 데이터베이스의 데이터를 반환해야한다. . :))

나를 혼란스럽게하는 부분은 코드를 재사용하는 것입니다. 코드를 재사용하는 유일한 방법은 데이터를 데이터 집합이나 데이터 테이블로 검색 한 다음 데이터를 반복하여 추가하는 것입니다. 목록에, 이것은 일반적으로 3 계층의 모범 사례이며 데이터 집합과 데이터 테이블없이이를 수행하는 방법입니다.

아래 링크의 예는 본질적으로 데이터 세트 또는 표를 사용하여 개체에 추가하는 방법을 보여 주지만 이것이 최선의 방법인지 묻습니다.

http://www.codeproject.com/Articles/36847/Three-Layer-Architecture-in-C-NET

감사

DataTable의 사용

Answer 1

는 특정 dotnetism이다. 그 이유는 데이터 구조에 대한 메타 데이터가 포함되어 있기 때문에 DataGrid (및 기타 구성 요소)은 리플렉션을 사용하지 않고 데이터를 자동으로 표시하기 때문입니다. 필자가 생각하기에 이것은 RAD의 MS Access 접근 방식의 유산 중 하나입니다. "비즈니스 사람"이 SQL 스키마에서 직접 사용자 인터페이스를 생성하여 응용 프로그램을 만들 수있게하는 의도였습니다. 본질적으로 계층화 된 디자인과는 반대입니다. 이 유산은 하이브 마인으로 유출 된 것 같습니다.

RAD 기능을 포기할 의향이있는 한 "일반"데이터 구조를 사용하는 데는 아무런 문제가 없습니다. 추세는 요즘 이러한 절충을 없애 버린 것 같습니다. (예를 들어, Web Forms의 강력한 형식의 데이터 컨트롤 및 MVC의 모델 바인딩 기능이 포함 된 경우)

또한 MVC를 만들기 전의 코드 프로젝트 기사는 일반적인 소프트웨어 아키텍처에 대한 좋은 지혜가 아닙니다.

Answer 2

데이터를 휴대해야하는 것은 전적으로 사용자의 필요에 따라 다릅니다.

DB에서 데이터를 검색하여 데이터 그리드에 바인딩하면 데이터 세트가 완벽한 솔루션을 제공 할 수 있습니다. 데이터가 자체 업데이트 상태를 추적하는 다른 방법을 원한다면 Entity Framework를 살펴 봐야합니다. 데이터를 검색하여 크로스 플랫폼 또는 교차 도메인 처리를 위해 웹 서비스를 통해 전송하는 경우 데이터를 다른 직렬화 가능 클래스에로드해야합니다.

아래 도움말을 참조하십시오. 그것은 조금 오래되었고 EF4를 타겟으로 삼았지만 다른 전략의 장단점을 아주 잘 요약합니다.

http://msdn.microsoft.com/en-us/magazine/ee335715.aspx

Answer 3

나는 그것이 3 층 디자인을 표시하는 간단한 방법이기 때문에 당신이 사용하는 데이터 테이블과 데이터 세트를 찾고 있습니다 샘플 생각 (이 시리즈의 세 기사가있다, 당신이 그들 모두를 읽으십시오). 이제는 Entity Framework가 샘플에서 언급 한 "데이터 액세스 계층"을 대체했습니다.

엔티티 프레임 워크가 데이터 액세스 레이어를 작성하기 전에 필자는 데이터베이스에서 작성한 일반 목록을 반환했습니다. 업데이트, 삭제 또는 삽입을 실행하려면 메서드에 매개 변수로 객체를 전달한 다음 객체의 속성을 SQL 문의 값으로 사용합니다. 언급 한 이유 때문에 그렇게하는 것이 더 좋았지 만 객체 정의 나 db 스키마를 변경하거나 (서로 다른 db를 함께 사용하는 경우도 있습니다) 서로 독립적으로 사용할 수 있었기 때문입니다.