새 프로젝트에서 사용하는 데이터 액세스 레이어에 영향을주는 요인은 무엇입니까?

Question

나는 클래스 소슨을 가르치게 될 것이고, 데이터 액세스 기술의 결정에 어떤 요소가 영향을 주는지 설명해야 할 필요가있다. 저는 형식화 된 데이터 집합, Linq to SQL, Linq to Entities, .netTiers, LLBLGen 및 SQL 연결 개체 및 명령 개체가있는 사용자 지정 호출과 같은 많은 데이터 액세스 방법에 익숙합니다. 내 고객 중 일부는 저장 프로 시저 만 사용하도록 허용하고 다른 항목에 대해서는 논의하지 않습니다. 일부 고객은 아직 .NET 3.5를 설치할 준비가되어 있지 않습니다. 일부 클라이언트는 모든 웹 응용 프로그램에서 중간 웹 서비스 계층을 필요로합니다. 대부분 유형 데이터 세트 및 사용자 정의 웹 서비스를 사용하거나 CodeSmith와 함께 .netTier를 사용합니다. 그 밖의 무엇을 생각해야합니까?

Answer 1

소프트웨어 프로젝트의 모든 선택과 마찬가지로 : 그것은 ... 하지만 내 생각에 가장 중요한 요소는 프로젝트 환경입니다.

이 구성

(나는이 목록은 어쨌든에서 완전 함을 주장하지 않습니다) : 개발 팀과 유지 보수 팀 (다른 경우) 설정

필수 기능

제약 조건 내에서

• 가능한 기술을 모든 클라이언트가 사용 가능한 모든 기술을 지원하는 것은 아닙니다. 레거시 시스템을 단계적으로 대체하거나 새로운 시스템을 도입 할 때 고려해야 할 사항입니다.
• 법률에 의해 설정된 제약

희망이 도움이 될 것입니다.

Answer 2

기억해야 할 중요한 점 중 하나는 데이터베이스가 응용 프로그램의 격리 데이터 저장소 일 필요는 없다는 점입니다. 다른 응용 프로그램 및 프로세스는 결국 대규모 또는 "엔터프라이즈"데이터베이스 (또는 응용 프로그램) 및 특히 충분한 시간이 주어진 데이터베이스에 대한 액세스를 최종적으로 요구할 수 있습니다.

그것은 고려하는 것이 중요합니다 :

ETL /로드/마이그레이션에게

외부 통합/동기화 (BizTalk/SSIS) 다른 응용 프로그램 (특히 웹 사이트, 모바일 애플리케이션 등)

보안/공격하여

재사용 표면 (다른 접근 방법보다 안전하지 않은 접근 방법 중 하나입니까?)

유지 관리 작업

가용성 - 데이터베이스는 연중 무휴로 사용됩니까? 하나의 접근법이 다른 것보다 더 나은 가용성을 제공 할 것인가?

또한 설계 고려 사항이 순서대로 있습니다. 더 빠른 선택이나 빠른 쓰기를 위해 튜닝을하고 있습니까? 하나의 데이터 액세스 설계가 다른 데이터 액세스 설계보다 우수 할 수 있습니다.

저는 단 한 개의 총알이 있다고 말하지는 않지만 모든 데이터 액세스 디자인 패턴은 "큰 그림"을 필요로한다는 점에 유의하십시오 - 오늘날의 우려 사항을 해결하고 내일의 가능성을 합리적으로 예측할 수 있습니다. 필요?

또한 외부 API 또는 일관된 데이터 액세스를위한 일부 프레임 워크를 제공 할 예정입니까? 직접적으로 또는 간접적으로 노출됩니까?

엔티티 프레임 워크/LINQ to SQL, 전통적 저장 프로 시저 및 NHibernate (기타)와 같은 다른 도구에 대해 생각할 수있는 부분이 있지만 먼저 기술 선택을 합리화하고 합리화해야합니다. 현재와 ​​미래의 필요에 적절합니다.

편집 : 미안하지만, 큰 것을 잊어 버렸습니다. 템플릿 기반 솔루션 중 일부는 스키마 변경 후 DAL을 다시 생성 할 수있는 능력을 제공합니다 (손으로 작성된 저장 프로 시저와 같은). 생산성 향상과 단점을 비교해 볼 가치가 있습니다.

Answer 3

저는 실제로 두 가지를 생각하고 있습니다. 첫 번째는 내가 중요한 데이터를 갖고 있는지 여부입니다. 테이블에 수백만 개의 행을 넣지 않으면 모든 기술이 충분히 빠르게 작동하기 때문에 어떤 기술을 사용할 지 중요하지 않습니다.

두 번째 문제는 LINQ를 사용하여 LINQ (SQL에, Entities, LLBLGen으로, 중요하지 않음)를 사용하여 데이터베이스를 쿼리하면 두 가지 중요한 사항을 찾을 수 있기 때문입니다.첫 번째는 쿼리를 작성하는 것이 매우 쉽고 둘째, 요구 사항이 변경되는 경우 LINQ가 필요한 두 프레임 워크간에 전환하는 것이 보통입니다.

Answer 4

나는 원래 게시물과 norbertB의 추가 내용 사이에 모든 것을 다뤘다고 생각합니다. 절대적인 제약 조건에서 시작하십시오 (클라이언트가 절대적이라고 말하면서도 한 번만 무언가에 대해 no라고 말하면된다는 사실을 기억하십시오. 그렇다고해서 마음을 바꿀 수 없습니다 ...). 절대 제약 조건으로 필드를 좁히면 다른 것들이 보입니다.

남겨 두지 않은 것 중 하나는 유연성입니다. 예를 들어, 두 개의 유사한 기술 중 하나를 선택하려고하면 업데이트 할 수있는 뷰를 지원할 수 있고 다른 뷰는 지원할 수 없다는 것을 알았습니다. 당시에는 업데이트 할 수있는 뷰가 필요하지 않았지만, 다만의 경우 ".