간단한 설명 : "Select x, y, z From Customer"는 데이터 액세스 계층에 있습니다.응용 프로그램 아키텍처에 배치 된 마이크로 도구가있는 위치
특정 도시의 고객을 필터링하는 것과 같은 쿼리에 논리가 있다면 비즈니스 계층에 필터링을 적용하고 메모리 내 고객 컬렉션에서 수행해야합니다. 지금이 코드 줄을 추가해야
var a = db.SingleOrDefault<Product>("SELECT * FROM SalesLT.Product WHERE ProductID = @0, 123);
: 지금 마이크로 ORM 도구를 생각하면
그들은 종종 같은 논리에 SQL 문을 보여? 비즈니스 계층 또는 데이터 액세스 계층에서?
비즈니스 계층에 속해야하는 문 내부에는 논리가 있습니다. 그런데 내가 가지고있다
내 BLL 안에 Select 문 ??
이것은 모두 혼란 스럽습니다.
3 계층 모델을 원할 경우 데이터 액세스 계층에서 db 컨텍스트 또는 마이크로 ORM 중 하나를 사용해야합니다.
3 계층 모델을 원한다면 DAL에 마이크로 ORM을 넣으십시오 (말한대로) 복잡한 ORM 등을 할 때 비즈니스 로직 계층에 무엇이 있습니까? – Pascal
내 의견으로는 개인적인 취향입니다. 서로 다른 BLL 클래스간에 SQL을 공유 할 필요가 없다면 SQL을 사용하는 메소드에 가까운 SQL을 좋아합니다. 그것은 변화를 쉽게 만든다. 간단한 작업의 경우 Dapper.Simple Crud과 같은 확장 메서드를 사용할 수 있으므로 동일한 작업을 반복해서 작성하지 않아도됩니다. 구현을 위해 github repo을 살펴볼 수 있습니다. Micro-ORM에 my talk에 대한 정보를 함께 표시합니다. 이 솔루션에는 Massive, Dapper, PetaPoco 및 Simple.Data에 대한 샘플 사용법이 있습니다. 서비스 클래스 중 하나에 link이있어 너무 많이 파고 들지 않아도됩니다. 의견이 있으시면 저에게 알려 주시기 바랍니다. :)
기존 ORM으로 어떤 작업을 했습니까? 그렇다면 어디에 넣었습니까? –
EF를 사용한다면 EF 자체가 DAL 인 것처럼 비즈니스 로직 계층의 리포지토리가 표시됩니다. – Pascal