회원에 대한 복잡한 계산을 수행하는 응용 프로그램이 있습니다. 각 회원은 자신의 프로필에 연결된 여러 미국 주를 가질 수 있습니다. 각 주마다 회원이 수료 한 각 과정마다 다른 계산이 있습니다.비즈니스 계층과 SQL 서버
현재 DB (SQL Server 2008)에서 계산을 수행 한 후 데이터를 앱 계층으로 보내서 기록을 볼 수 있으며 각 과정의 인증서를 다운로드 할 수 있습니다.
비즈니스 로직 레이어가 있지만 그다지 많이 발생하지는 않습니다. 이 질문을 많이 받았지만이 계산을 수행해야한다고 생각하는 부분은 무엇입니까? 비즈니스 계층 또는 데이터베이스? 나는 앞뒤로 가고있다 !!
나는 기본적으로 SQL 서버에 아무것도 할 것이라고 :
의 데이터를 합산, 계산의 많은, 평균 등을 수행하고 단일 값을 반환합니다. 많은 양의 데이터를 중간 계층으로 전송할 때 실제로 열을 요약 할 필요가 없습니다.
행/세트 기반 조작이 많습니다. 많은 양의 데이터를 복사, 삽입, 업데이트해야 할 필요가있는 경우 해당 데이터를 모두 중간 계층으로 드래그 한 다음 다시 서버로 보내면됩니다. 서버에서 바로 실행하십시오. 또한 : T-SQL은 간단히
이 될 수 귀하의 중간 계층에서 무엇보다 (주위 데이터를 셔플 등) 집합 기반 작업을 다루는 훨씬 빠르다 : 클라이언트에 많은 양의 데이터 전송을 방지하려고 (데이터베이스에 저장된 파일을 다운로드하려는 경우 또는 실제로 에이 필요하다면 앱의 객체에 구체화되어 200 개의 행이 어딘가에 표시되거나 운영되도록해야합니다.)/중간 계층/비즈니스 계층 on)
자주 간과되는 기능 중 하나는 데이터베이스 테이블의 계산 열입니다. 예를 들면. 주문 합계와 세금 및 배송료를 합계로 합산 한 것, 성과 이름을 표시 이름으로 합치는 것이 좋습니다. 이러한 종류의 것들은 비즈니스 로직 계층에서만 처리하면 안됩니다. 데이터베이스의 데이터를 직접 처리하면 데이터베이스 테이블을 검사하고 SQL Server의 데이터를 볼 때 해당 "계산 된"값을 사용할 수 있습니다 MGMT 스튜디오 ...
나는 그것이 등 광범위한 로직 검사, 문자열 구문 분석, 패턴 매칭 및 필요한 경우 중간 계층/비즈니스 로직 계층
에 넣어 것입니다; T-SQL은 (그것이 비즈니스 논리 연산의 더 필요한 경우 그
처럼에 대한 데이터 또는 무언가를 검증하기 위해 일부 데이터를 얻을 수있는 웹 서비스를 호출 같은 것들을 필요한 경우 것들
에 짜증
그러나 이것은 단지 "거친"지침 일뿐입니다. 항상 각 경우에 대한 디자인 결정이므로 엄격한 규칙을 믿지는 않습니다. 당신의 마일리지는 경우에 따라 다양 할 수 있으므로, 주어진 작업에 가장 적합한 접근 방식을 선택하십시오.
데이터베이스 (저장 프로 시저) 내부에 비즈니스 로직 코드가없는 데 도움이됩니다. 응용 프로그램에서 직접 가져와 아키텍처에 적합하도록하는 것이 훨씬 좋습니다. 이 SQL 코드에는 비즈니스 로직이 포함되어 있으며 그곳에 아무 문제가 없습니다. (sprocs에서 데이터 나 유지 보수 관련 코드가있는 데는 아무런 문제가 없습니다.)
비즈니스 로직 계층이 많이 수행하지 않고 SQL Server의 데이터를 호출자에게 전달하는 중이라면 어쩌면 필요하지 않을 수도 있습니다.
저장 프로 시저는 데이터베이스 작업을 처리하고 비즈니스 논리를 "숨기지"않는 한 매우 유용합니다. 그러나 많은 작업에서 저장 프로 시저를 사용하면 매우 유용 할 수 있습니다. 나는 단지 그들을 세계적으로 "금지"하지 않을 것입니다. –
당신 말이 맞습니다. 내가 편집 했어요. – usr
고마워요, 기본적으로 어떤 과정에 참석했는지에 관한 데이터를 수집하고 나면 등록 된 각 주마다 보고서를 모든 크레딧과 함께 회원에게 보냅니다. 나는 DB가이 계산을 수행하는 올바른 장소라고 생각한다. 이 올바른 일을하는지 궁금해하는 순수 vb.net/c# 사람이었습니다. 물론 그는 그것이 BLL에서 모두 이루어져야한다고 주장한다. 각 상황이 다릅니다. – mick
비즈니스 로직 계층은 과도한 작업을 수행 할 대상이 아니기 때문에 주제의 언어로 엔티티를 추상화하는 것이 목적입니다. 따라서 비즈니스 계층은 해당 공간에서 작업해야하는 모든 계층/응용 프로그램에 대해 공유되고 일관된 접근 방식을 제공하는 데 사용될 수 있습니다.
기술적 인 사항을 강조하기 위해 궁극적 인 목표는 해당 논리 영역에서 작업하는 모든 응용 프로그램에 대해 조직 전체에서 비즈니스 논리 계층을 사용하는 것입니다. 나는. 서비스 등에 포장되어 있습니다.
이 작업을 수행하는 작은 응용 프로그램의 실제 세계에서 비즈니스 로직 계층은 때때로 부록처럼 느껴집니다. 트릭은 또한 어떤 유스 케이스가 비즈니스 레이어에 대한 테스트로 구현되어야하며, 공용 인터페이스가 어떻게 보일 것인가를 생각할 수있는 또 다른 방법을 제공한다는 것을 기억해야한다.
비즈니스 로직 계층이 작업을 완료하는 방법은이를 호출하는 응용 프로그램 부분에서 숨겨져 있어야합니다.
따라서 계산이 비즈니스 로직 계층에서 적절한 표현을 제공하는 한 가장 효율적인 방식 (예 : sql)으로 데이터를 계산할 수 있습니다.
나는 데이터베이스에서 계산을 항상 수행 할 것입니다 ** ** 귀하의 계산이 많은 데이터 **를 중간 계층으로 반환해야한다면 ** 예를 들어 계산 된 'SUM'. 왜 그 모든 데이터를 주위에 보내는 것을 귀찮게합니까 ?? 데이터베이스는 일부 값을 합산하고 단일 결과를 다시 전송할 수있는 기능을 갖추고 있습니다. ** 많은 ** 효율적인! 따라서 많은 일을 할 필요가있을 때마다 서버에서 수행하십시오. –
@marc_s에 동의합니다. SQL Server는 데이터를 빠르고 효율적으로 처리하도록 설계되었습니다. –