내 프로젝트의 여러 "부품"(예 : WinForms app)은 L2SQL을 기반으로 코딩 한 DAL을 사용합니다. 여러 웹 응용 프로그램을 혼합하여 넣고 싶지만 DAL이 웹 응용 프로그램보다 훨씬 많은 데이터를 "제공"한다는 점이 문제입니다. 더 많이.Linq to SQL, WebServices, Websites - 모두 계획
웹 서비스에서 웹 사이트가 필요로하는 데이터를 래핑하고 DAL에 직접 연결하는 웹 사이트 대신 DAL에 액세스하는 웹 서비스를 통과하는 것이 좋을까요?
오버 헤드가 많을 것이라고 생각하지만, 웹 애플리케이션에 실제로 필요한 것보다 훨씬 많은 데이터를 액세스 할 수있는 "능력"이 있다는 것을 느끼는 것이 맘에 들지 않습니다.
모든 입력 사항을 매우 높이 평가할 것입니다. 도움 주셔서 대단히 감사합니다.
웹 서비스를 만들거나 응용 프로그램에 필요한 데이터 만 제공하는 repository 레이어를 추가 할 수 있습니다. 리포지토리는 디커플링 레이어라는 추가적인 이점을 갖기 때문에 모의 리포지토리를 제공하여 응용 프로그램을 단위 테스트하기가 더 쉽습니다.
다른 프론트 엔드 (예 : 웹 UI와 WPF 또는 Silverlight UI)를 만들 계획이라면 웹 서비스는 빌드 할 공통 데이터 기반을 제공하고 액세스 할 수 있기 때문에 많은 의미가 있습니다 계층별로
데이터 액세스 레이어가 모든 데이터를 IQueryable로 가져 오는 경우 DAL을 쿼리하고 더 정확하게 db 호출을 드릴 다운 할 수 있습니다.
매우 간단히보기 blog entry Linq to SQL을 사용하여 저장소 및 서비스 계층에 썼습니다. 내 기사는 MVC를 기반으로하지만 리포지토리 및 서비스 레이어 개념은 WebForms, WinForms, Web Services 등에서 잘 작동합니다.
여기서도 핵심은 리포지토리 또는 Dal에게 객체 AsQueryable을 반환하는 것입니다. 마지막으로 데이터 요청에 실제로 투입 될 때까지 기다립니다.
귀하의 구조는 당신이 당신을 위해 개발 응용 프로그램에 따라 특정 전화를 사용자 정의 할 곳 층 당신의 서비스 안쪽이
Domain Layer
Repository Layer (IQueryable)
Service layer for Web App
Website
Service layer for Desktop App
Desktop App
Service layer for Web Services
Web Service
처럼 보일 것입니다. 이렇게하면 ORM을 바꿀 때까지 수정할 필요가없는 완전한 저장소를 유지하면서 앱별로 더 큰 보안과 구성을 할 수 있습니다 (ORM을 바꿔야한다고 결정한 경우)
이 경우에 당신이 필요로하는 것 이상으로 갖는 것이 본질적으로 잘못된 것은 아닙니다. .NET 4 Client Profile 전체에는 50MB가 넘는 어셈블리, 클래스 등이 포함되어 있습니다. 전체 경력 중 5 %를 사용할 수 있습니다. 그렇다고해서 필자가 필요로 할 경우에 대비하여 모든 것을 사용할 수 있다는 것에 감사하지 않습니다.
데이터의 일부에 액세스하지 않아야하는 개발자에게 DAL을 제공하려는 경우 래퍼를 작성하거나 새 DAL을 파생시킵니다. 오버 헤드를 수용 할 수 있다고 확신하지 않는 한 서비스 경로를 피할 것입니다.
부분적으로 동의하지 않습니다. @Isaac이 "데이터"가 웹 서비스가 필요로하는 것 이상의 방법이라고 말하면 대부분의 정보가 쓸모없는 많은 정보를 쿼리하고 싶지 않습니다. 예. .NET 프레임 워크는 크고 일반 앱에 필요한 것보다 훨씬 많은 것을 가지고 있지만 데이터베이스를 방문하는 것과 같은 방식으로 모든 단일 API 호출에서 전체 50MB 파일을 폴링하지는 않습니다. –
"필요한 것보다 많은 데이터"가 의미하는 바에 달려 있습니다. * 예상치에 * 너무 많은 데이터가 포함 된 경우 새 DAL을 파생하고자합니다. 불필요한 쿼리가있는 경우에는 관련없는 데이터에 액세스하지 않아야하는 개발자가 라이브러리를 사용하지 않는 한 비용이 들지 않습니다. –
예 매우 맞습니다. 불필요한 검색어는 여기 또는 여기에 없습니다. 추가 데이터는 현재 DAL이 어떻게 구성되어 있는지에 따라 엄청난 성능 차이가 발생할 수 있습니다. –
당신이 옳은 길을 걷고있는 것처럼 들립니다. 많은 응용 프로그램에서이 데이터를 사용하면 DTO가있는 서비스를 통해 몇 가지 이점을 얻을 수 있습니다.
"저장소"링크는 Repo의 'AsQueryable'작성에 관해 전혀 말하지 않습니다. Queryable 리포지토리를 사용하면 기존 내용을 다시 작성하지 않고도 여러 응용 프로그램의 db 호출을보다 효과적으로 구성 할 수 있습니다. (물론 응용 프로그램 내에서 기존 db 호출에 대한 초기 재 작성을 수행 할 준비가되어 있어야 함). 이것이 저장소 계층이 서비스 계층과 잘 어울리는 이유입니다 ... 다른 응용 프로그램에 대해 다른 서비스. –
@rock :'IQueryable' 객체를 반환하겠다는 결정은 소비자가 갖고 싶은 컨트롤의 정도에 달려 있습니다. 일반적으로,'IQueryable' 객체는 Linq to SQL 객체 트리에있는 다른 링크 된 객체에 액세스 할 수 있으며 추가 Linq 쿼리를 실행할 수 있습니다. 이것은 일반적으로 더 얇고 강력한 저장소 계층을 생성하지만 (게으른로드는 좋음) 제어 및 보안상의 이유로 항상 이렇게하지 않는 것이 좋습니다. 때로는 목록이나 단일 엔티티 객체 만 있으면됩니다. –
네, 그렇습니다.하지만 서비스 레이어에 보안과 컨트롤을 추가 할 수는 없습니까? (이것은 내가하는 일입니다.) –