2009-10-08 4 views
2

저는 새로운 시스템에서 ASP.NET 웹 애플리케이션에 대한 객체 지향 접근 방식으로 전환하고 있습니다.실용적인 객체 지향 설계 질문

저는 대부분의 사람들이 잘 알고있는 공통적 인 구조를 가지고 있습니다. 여러 부서가있는 학교 구조가 있습니다. 단일학과에 속하는 과목들; 여러 과목에 속하는 학생. 부서보기에서

나는, 나는 부서에 속한 모든 과정을 나열하고 나는 그러나 이러한 개별 코스보기에서 등 여성 재학생, 인출의 수, 번호 남성/

을 각 과정에 대한 집계 수치를 원하는 과정, 성별 등과 같은 세부 사항과 함께 학생들의 실제 목록이 필요합니다.

그리고 다른 코스에 등록한 것을 포함하여 학생에 대한 모든 세부 정보가 표시되는 개별 학생보기 등

이전에는 광고가 있었을 것입니다. 액세스 레이어에서 각각의 경우에 필요한 데이터를 반환하고 SQLDataReader 또는 DataSet (VB.NET에서 작동)으로 반환합니다. 이제 객체 지향 접근법에서 이것을 모델링하려고합니다. 객체를 생성 할 때 DAL에 객체를 만들고이를 BLL에 반환합니다. 개체에 집계 된 세부 정보가 필요할 때 어떻게 처리해야할지 모르겠습니다. 예를 들어, 코스 목록이있는 부서보기에서는 각 코스에 대한 집계가 있습니다. 저 경량 코스 오브젝트가 집계 된 값을 저장하는 부서에 경량 코스 오브젝트의 콜렉션을 저장합니까?

다른 시나리오에서 필요한 추상화 수준이 다르며이를 처리하는 가장 좋은 방법이 확실치 않습니다. 집계를 저장하는 매우 기본적인 코스 객체가 있고 전체 세부 사항을 저장하는 하위 객체가있는 객체 모델을 사용해야합니까?

위와 같은 것들을 모델로 만드는 방법을 이해하는 데 도움이되는 유용한 리소스가 있다면.

+0

지금까지 답변 해 주셔서 감사합니다. 나는 여전히 특정 접근법에 대해 완전히 확신하지 못하고있다. Mark Seemann의 도메인 중심 접근 방식에 대해 아직 읽지는 않았지만 나중에 살펴볼 것입니다. 나는 Anton와 동의하며, DB에서 내 집계를 수행하기를 원한다. 그러나 나는이 ORM에 대해 확신하지 못한다. 성능에 나쁜 영향을 미쳤는가? – Nick

+0

아마도 객체 지향 접근법이이 시나리오에 이상적이 아니며 아마도 너무 많은 합병증을 추가 할 것이라고 생각하는 사람이 있습니까? – Nick

답변

4

지나치게 복잡하게하지 말고 불필요한 작업을 수행하지 마십시오. 데이터베이스는 데이터 조작과 관련하여 완벽하기 때문에 DB를 집계하십시오. 사물의 코드를 측면에서 개체 모델에 하나 이상의 오브젝트를 추가하고 당신은 벌금과 멋쟁이 수 있습니다 :

class CourseStats 
    string Name { get; } 
    int Enrollments { get; } 
    int Withdrawals { get; } 

집계를 수행하는 SQL은 매우 간단합니다. 그러나 ORM (생각한 사람 NHibernate) 또는 덜 정교한 결과 세트 매퍼 (생각한 사람 BLToolkit)를 사용해야합니다. 실제로 이러한 개체를 수동으로 수화하고 싶지는 않습니다.

추가 이점은 쿼리 결과를 모두 캐시 할 수 있고 코스 관련 변경 사항이 발생하는 즉시 캐시를 무효화 할 수 있다는 것입니다.

0

부서가 거의없고 코스 수가 적은 경우 모든 것을로드하고 오브젝트를 계산하도록합니다. 즉 부서에서 코스 목록을 반복하고 필요한 것을 합산합니다.

대체 접근법은 일부 사용자 지정 원시 SQL을 사용하여 데이터베이스에 대해 합계를 실행하는 것입니다. 이것을 DAL에서 숨길 수 있습니다. DAL은 예를 들어 가상 코스 (데이터베이스에는 존재하지 않지만 합계를 포함)를 리턴합니다.

세 번째 방법은 부서 개체의 어딘가에 이러한 값을 유지하고 코스가 변경/추가/제거 될 때마다 업데이트하는 것입니다.

1

실제로 많은 사람들이 고심하고있는 큰 문제입니다.

지금까지 내가이 문제에 대한 생각의 두 개 이상의 학교가 식별 할 수있었습니다 같이 게으른 로딩을 지원하는 OR/M과

  • 영구-무지 도메인 객체는
  • 도메인 기반 설계 및 명시 적으로 모델링 된 (명시 적으로로드 된) 집계

Jeremy Miller는 일부 지속성 패턴을 조사하는 article in MSDN Magazine을가집니다.

Domain-Driven Design에는 집계 모델링에 대한 좋은 토론이 있습니다.

+0

의견을 보내 주셔서 감사합니다. Mark, 저는 MSDN Magazine 기사를 아주 잘 읽었습니다. 린 프로그래밍 (Lean Programming)이라는 섹션에서 저자는 데이터 액세스 전략에 대해 이야기하고보고 애플리케이션의 경우 SQL과 데이터 세트 만 사용한다고 말합니다. 어쩌면 내 응용 프로그램이보고 범주에 속하는 것으로 생각할 수 있으며이 특정 사례에서 가장 좋은 접근 방법 일 수 있습니다. – Nick

+0

전적으로 동의합니다. 보고는 내가 계층화 및 추상화를 피하고 DB에 직접 파티를 열지 않는 극소수의 경우 중 하나입니다. :) –

0

.NET으로 작업하는 경우 조사해야 할 사항은 LINQ to SQL입니다. DAL에 매우 우아한 인터페이스를 제공 할 것입니다. LINQ를 사용하면 BLL에 aggregate queries을 작성하여 배관 코드를 저장하고 원본 전체에 퍼진 불쾌한 SQL 코드 조각을 저장할 수 있습니다. 집계 SQL 쿼리의 이전 링크에서 예제는 LINQ로 표현 : 내 경우에 나는 내가 대신 사용하고 MS SQL 서버를 사용하지 않지만 내가 LINQ 내 데이터베이스 계층에 걸쳐 전환했습니다

var averageOrderTotals = 
    customers. 
    Select(c => new { 
     c.Name, 
     AverageOrderTotal = c.Orders.Average(o => o.Total) 
    }); 

DbLinq 라이브러리

마지막으로 수행하고자하는 작업은 데이터베이스 액세스 계층을 수용 할 수 있도록 클래스를 수정해야한다는 것입니다. 그렇게하면 해당 솔루션이 매우 취약 해집니다.