Linq to SQL 및 논리적 파티셔닝 (DAL, BLL)

Question

.Net에서 우리 사이트 중 하나를 재 구축 할 예정입니다. 필자는 많은 기사를 읽었으며 프로젝트를 데이터 액세스 레이어 (DAL), 비즈니스 로직 레이어 (BLL) 및 프리젠 테이션 레이어 (이전 ASP에서 나왔습니다.). 나는 또한 SQL에 Linq을 정말 좋아한다.

Linq to SQL은 급속한 개발을 목표로하므로 Linq에서 SQL에 DAL, BLL 및 프리젠 테이션 계층을 실제로 적용 할 수 있습니까? DAL이 BLL에서 수정 될 수있는 엔티티 또는 linq 코드를 반환 할 것인가? Linq와 SQL 간의 DAL과 BLL 간의 관계는 합의가없는 불분명 한 주제 인 것 같습니다. 그리고 이것은 우리에게 큰 도약 이었기 때문에 무엇이든 뛰어 들어가기 전에 좋은 게임 계획을 갖고 싶습니다.

형식화 된 데이터 집합이 더 필요해 보이지만 Linq과 비슷한 것을 얻을 수 있다면 그 경로를 선택하십시오.

저는 nHibernate 및 다른 타사 라이브러리에서 멀리하고 싶습니다.

Answer 1

우리가 묘사 한 내용을 정확하게 구현하고 있으며 L2S를 사용하고 있습니다. DAL과 BLL 간의 관계가 다소 불투명하지만, 우리는 별개의 BLL과 별개의 DAL을가집니다. 우리의 모든 논리는 BLL에 있고 모든 데이터 검색/수정은 DAL에 대한 호출 (LINQ 호출 사용)을 통해 수행됩니다.

Google 앱은 입력 된 데이터 세트를 사용하지 않습니다. 객체를 나타 내기 위해 엔티티 클래스를 만들었습니다. 이제까지 몇 개월을 보냈으므로 데이터 세트로 돌아가는 것을 보지 못했습니다.

또한 "나는 급속한 개발을 목표로하고있다"며 L2S에 매달리지 않을 것이다. 이것은 시제품 제작 도구처럼 들립니다. 우리는 그것을 산업 강도 도구로 생각하고 있습니다. 이것은 오히려 사람들이 EF를 사용하기 때문에 마이크로 소프트가 지금 말한 것과 반대되는 것일 수 있습니다.

랜디

Answer 2

나는 다시 한 걸음을 다시 한 번 요구 사항을보고하는 것이 좋습니다.

실제 3 계층 (다른 시스템에 물리적으로 배치되어 있습니까?) 또는 응용 프로그램의 논리적 파티션 만 필요합니까?

제가 작성한 첫 번째 큰 응용 프로그램에서이 실수를 정확하게했습니다. 필자는 물리적 인 3 단계를 필요로하지 않았으며 결코 필요로하지 않을 것입니다. 가장 눈에 띄는 결과는 Linq2Sql이 연결 추적 변경을 지원하지 않는다는 것입니다. 엔티티에 대한 변경 내용 추적. 이 한계를 극복하기 위해 Linq2Sql Entity Base을 사용했지만 지속성 무시 (Persistence Ignorance)의 개념을 매우 악용했습니다 (나중에 항상 더 잘 압니다.).

실제 n-tier를 사용하면 응용 프로그램 아키텍처에 많은 영향을 미칩니다.

메시지 전달, 데이터 전송 객체 등이 필요합니다. Linq2SQL은 괜찮은 ORM이며 LINQ와의 긴밀한 통합은 고유 한 가능성을 제공합니다. 다른 ORM은 여전히 ​​여기에 따라갈 시간이 필요합니다. NHibernate 3.0은 여기 터널 끝에있는 빛입니다. Linq2SQL은 간단한 데이터 모델을 갖고 "테이블 당 클래스"방식으로 매핑 할 수있는 훌륭한 ORM입니다.

연결이 끊어진 변경 내용 추적 (n 계층으로 전환하는 경우 필요합니다)의 경우 다른 ORM이 더 잘 지원됩니다.

그리고 마침내

:

내가 특히주의 할 것 이러한 상황에서

(우리가 고전적인 ASP에서오고있어 지금이 은 우리에게 엄청난 단계). 스위칭 기술은 종종 과소 평가됩니다. 팀에서 가장 똑똑한 프로그래머조차도 기술에 대한 경험이 없기 때문에 잘못된 결정을 내릴 수 있습니다. 그럼에도 불구하고 새로운 방식으로 가고 기술을 향상시키는 것이 중요합니다. 결코 실패하지 않는 사람들은 결코 성공하지 못할 것입니다.

Answer 3

IMHO, LINQ to SQL은 현재 사용 가능한 최상의 선택입니다. 정말 고통스럽고 거의 재미있는 데이터로 작업합니다. :-) LINQ to SQL에 관심이 있으시면 PLINQO 프로젝트를 살펴 보겠습니다. 더 나은 전체 솔루션을 만들기 위해 LINQ to SQL에 대한 몇 가지 큰 개선 사항이 있습니다.

Answer 4

나는 L2S 가 DAL이라고 말하고 싶습니다. 별도의 클래스에있는 L2S + 비즈니스 로직은 병합 된 DAL + BLL, DAL 측은 L2S 런타임, L2S 생성 코드 (datacontext, 엔티티 클래스 등)가됩니다.

L2S에서 생성 된 부분과 엔티티 및 datacontext의 확장이 별도의 DLL에 있고 별도의 비즈니스 로직이 별도의 dll/service/etc에 있도록 쉽게 분리 할 수 ​​있습니다. 그러나 많은 경우에 이들을 분리 할 필요가 없습니다.

L2S를 사용할 때 DAL + BLL로 분리해야하는 한 가지 이유는 이동 중에 다른 데이터 액세스 기술로 이동하거나 둘 이상의 데이터 액세스 기술을 사용하는 경우입니다. 별도의 DAL과 L2S 관련 자료가 분리되어 있으면 DAL을 쉽게 전환 할 수 있습니다. 이러한 이유로 DAL + BLL을 분리하려는 경우 L2S DAL-DLL은 엔티티 클래스, 파생 클래스 또는 프로젝션 클래스, 엔티티 또는 컬렉션 (List 등)을 가져 오는 메소드를 노출해야하지만 DataContext는 DAL 내부에 유지해야합니다 L2S 관련 항목 (L2S 쿼리 등)이 BLL로 유입되는 것을 피하기위한 클래스입니다.

JMHO. DAL 및 BLL 개념은 더 이상 의미가 http://www.thinqlinq.com/post.aspx/title/linq-tools

Answer 5

내가 LINQ와 생각 : 다른 사람이 L2S 도구를 언급 한 이후

---

는, 여기가 무엇보다 완전한 요약입니다. 그래서 linq 클래스와 일부 getters & setter 코드 (부모) 폴더 아래의 '도메인'폴더 아래에 배치했다. 그런 다음 'Repository'클래스와 'FontEnd'클래스를 만들었습니다.