2014-01-11 3 views
2

큰 클래식 ASP 웹 응용 프로그램을 n 계층 접근 방식을 사용하여 ASP.Net MVC로 변환하는 중입니다. DAL에서는 ADO.Net을 사용하여 데이터베이스를 쿼리하고 쿼리를 개체로 변환합니다. 나는 또한 계산과 검증 같은 것들에 대한 BLL을 가지고있다.데이터 액세스 레이어에서 계산

제 질문은 쿼리를 개체로 변환하기 위해 계산이 필요할 때 DAL에서 계산을 수행하는 것과 관련이 있습니다.

public class Invoice 
{ 
    public int InvoiceID { get; set; } 
    public DateTime InvoiceDate { get; set; } 
    public decimal InvoiceTotal { get; set; } 
    public List<InvoiceLineItem> LineItemList { get; set; } 
} 

그래서 데이터베이스 쿼리에서 개별 항목을 변환 내 코드는 다음과 같습니다 :

decimal InvoiceTotal = 0; 
var LineItem = new InvoiceLineItem(); 
while (Reader.Read()) 
{ 
    LineItem.ItemID = Extensions.SafeGetInt(Reader, "ItemID"); 
    LineItem.Price = Extensions.SafeGetDecimal(Reader, "Price"); 
    LineItem.Quantity = Extensions.SafeGetInt(Reader, "Quantity"); 
    LineItemList.Add(LineItem); 

    InvoiceTotal = InvoiceTotal + (LineItem.Price * LineItem.Quantity);  
} 

Invoice.InvoiceTotal = InvoiceTotal; 
etc ... 

그래서 여기에 예를 들어 라인 항목뿐만 아니라 요약 정보가있는 송장 시스템을 고려 부여하려면 내 질문 : 내 n 계층 아키텍처를 고려할 때 DAL이 InvoiceTotal 계산을 수행하기에 적합한 곳입니까? BBL의 업무 중 일부가 계산을 수행하는 것을 고려할 때, 이는 DAL과 BLL 간의 관심사 분리를 위반합니까? 아니면 계산을 수행하는 BBL의 기능을 문자 그대로 사용하고 있습니다. 모델을 채우기 위해 계산이 필요한 경우 DAL에서 계산을 수행하는 것이 좋습니다. DAL에서 InvoiceTotal 계산을 수행하는 것이 매력적 인 이유 중 하나는 한 번만 송장 항목 레코드를 한 번 반복해야하기 때문입니다. InvoiceTotal을 얻기 위해 별도의 InvoiceTotal 함수를 다른 곳에서 만든 경우 두 번째 레코드를 반복해야합니다.

편집 : 실제 질문은 계산이 DAL에서 허용되어야하는지 여부가 아니라 InvoiceTotal이 내 모델에 있어야하는지 여부입니다. 데이터베이스 정규화 관점에서는 합계를 광고 항목에서 계산할 수 있기 때문에 필요하지 않습니다. 이 경우 InvoiceTotal을 내 모델에 포함해서는 안되지만 내 ViewModel에 있어야합니다.이 경우 내 DAL에서 계산할 필요가 없습니다. 성능상의 이유로 데이터베이스 정규화 문제를 무시하고 InvoiceTotal을 내 모델에 포함시킬 수는 있지만, InvoiceTotal을 데이터베이스에 유지할 경우 내 모델을 채울 때 계산을 수행하지 않아도됩니다. 데이터베이스.

학습 교재 : DAL에서 계산을하고 싶다면 모델에 결함이있을 수 있습니다.

데이터베이스에 기록하기 전에 당신이 유일한 장소를하지 않도록 내가 비즈니스 로직 계층

송장 총의 초기 계산 응용 프로그램에서 사용할 수 있어야에 계산을 추가 할

+0

평균 CPU는 초당 수백만 번의 반복 작업을 수행 할 수 있습니다. 그것은 당신의 아키텍처를 결정해서는 안됩니다. 계산은 비즈니스 계층에 속합니다. – CodeCaster

+0

계산은 비즈니스 계층에 속합니다. Persisting 및 Querying 데이터는 데이터 계층에 속합니다. – MUG4N

+0

CodeCaster, 나는 또한 건식하려고 노력 중입니다. 송장 합계를 계산하고 레코드를 반복하는 별도의 함수를 만든 경우 DRY를 위반하지 않습니까? –

답변

3

그 합계는 레코드를 검색 할 때 계산됩니다.

비즈니스 논리 계층에 추가해야하는 또 다른 이유는 데이터를 쓰고 읽는 데 DAL 계층을 집중시키는 DAL에서 반환 된 회선 데이터에서 파생 될 수 있다는 것입니다. 이것은 또한 한 곳에서 계산을 유지합니다.

그러나 인보이스 합계가 일단 전송되면 고정되므로 처음 저장시 초기 값을 작성한 다음 수동 수정을 허용 할 수 있습니다. 이 경우 송장 총계 계산은 비즈니스 계층에서 수행되지만 값은 재 계산없이 데이터베이스에 쓰여지고 데이터베이스에서 검색됩니다.

+0

사실, 내 오류는 InvoiceTotal이 전혀 모델에 있지 않아야하지만 ViewModel에서만 (예 : InvoiceViewModel)이라고 생각합니다. 데이터베이스 정규화의 관점에서 볼 때 송장 총계는 데이터베이스에 유지할 필요가 없습니다. 이는 송장 항목에서 계산할 수 있기 때문입니다. 내 모델에 InvoiceTotal을 포함하지 않고 내 ViewModel에서만 사용하기로 결정한 경우 InvoiceTotal은 InvoiceModel에 없으므로 별도의 함수 여야합니다. –

+0

순 송장 합계에 동의합니다. 총 합계에는 미래에 변경 될 수있는 세금 요소가 계산에 포함됩니다. 이 경우 나는 확실히 그것을 데이터베이스에 씁니다. –

+0

당신의 답은 제 모델이 결함이 있음을 보여 주었기 때문에 포인트를 얻었습니다. –

관련 문제