대형 응용 프로그램의 데이터 액세스 전략

Question

.NET 3.5sp1에서 VB6 응용 프로그램을 다시 작성하려고합니다. VB6 응용 프로그램은 꽤 잘 작성되어 있으며 데이터 계층은 저장 프로 시저를 기반으로합니다. 나는 Linq2SQL/Entity Framework/NHibernate/SubSonic과 같은 자동화 된 것으로 가고 싶다. 틀림없이, 나는 쓰레기 프로젝트 이외에이 도구들을 사용하지 않았습니다.

나는 이러한 모든 선택에 대해 두려워 할 수있는 잠재적 인 문제는 속도입니다. 이 솔루션은해야 할 것,

ALTER PROCEDURE [dbo].[lst_Customers] 
@intID  INT = NULL 
,@chvName VARCHAR(100) = NULL 
AS 

SELECT Customer_id, Name 
FROM dbo.Customer 
WHERE (@intID IS NULL OR @intID = Customer_id) 
AND (@chvName IS NULL OR Name like ('%' + @chvName + '%')) 
ORDER BY name 

가 음속 Linq2SQL/엔티티 프레임 워크/NHibernate에 /에서 단일 행을 검색하려면 : 예를 들어, 지금은 하나의 행 (또는 전체 목록), 나는 다음의 sproc를 사용을 검색 할 전체 목록을 클라이언트에게 가져다가 필요한 행을 찾으십시오.

따라서 데이터 도메인이 큰 응용 프로그램의 데이터 액세스 전략에 대한 합의는 무엇입니까?

Answer 1

나는 악마의 옹호자와 놀고, 적어도 저장 프로 시저를 고수 할 것을 권한다. 이는 다시 작성하고 디버그 할 필요가없는 코드 조각을 나타냅니다. This article Joel Spolsky가 작성한 Very Own [tm]의 완전한 재 작성을 피하기위한 일관된 논증을 제시합니다.

'greenfield'프로젝트가 있으면 원하는 것을 사용할 수 있으며 O/R 매퍼가 좋은 선택 일 수 있습니다. 그러나, 당신은 이미 VB6 애플 리케이션이 잘 쓰여 있다고 말했다. sprocs가 잘 쓰여 있다면, 당신은 당신의 앱을 무료로 얻을 수 있으며 이미 디버깅을하게되며, 데이터베이스 스키마를 재활용하고 데이터 마이그레이션으로 인한 고통을 피할 수 있습니다.

Fowler의 Patterns of Enterprise Application Architecture은 유지 관리 문제를 일으키지 않고 저장 프로 시저와 잘 연동되는 데이터 액세스 레이어를 디자인하는 데 유용한 정보를 제공합니다.

이것은 Oracle/Java 애플리케이션에서 매우 일반적으로 수행됩니다. 많은 레거시 오라클 애플 리케이션은 PL/SQL에서 많은 수의 스토어드 프로 시저 코드를 가지고 있습니다. 이것은 Oracle Forms의 클라이언트 - 서버 시대의 표준 아키텍처였습니다. Java에서 sprocs에 대한 랩퍼를 작성하고 랩퍼 위에 사용자 인터페이스를 빌드하는 것이 일반적입니다.

다른 포스터 중 하나는 Subsonic이 sprocs 용 래퍼를 생성 할 수 있다고 언급했습니다.

옛날 옛적에 필자는 PL/SQL sprocs를위한 개념 증명 Java/JDBC 래퍼 인 IIRC를 생성하는 데이터 사전 해킹을 할 기회가있었습니다. IIRC는 하루 정도 걸렸습니다. 그것이하는 것이 그렇게 어렵지 않다는 것을 감안할 때, 나는 당신이 이것을하기 위해 선반에서 내릴 수있는 것들에 대한 선택의 여지가별로 없다는 것을 발견하면 놀랄 것입니다. 꼬집음으로, 당신 자신의 것을 쓰는 것도 그다지 어렵지 않습니다.

Answer 2

Linq-to-SQL, Entity Framework 또는 NHibernate에 대해서는 말할 수 없지만 SubSonic에 관심이 있습니다. 그것을 가진 나의 경험은 압도적으로 긍정적이었다.

이러한 도구의 작동 방식은 일반적으로 관리 코드에서 매개 변수화 된 쿼리를 작성하고 해당 액세스를 클래스에 캡슐화 한 다음 해당 클래스를 앱에 표시하는 것입니다. 완전히 생성 된 DAL 록.

매개 변수화 된 쿼리를 사용하면 "전체 목록을 클라이언트로 가져와 내가 필요한 행을 찾아야합니다"라는 우려가 처리됩니다. 그들은 where 절을 지원하고 필요한 다른 행을 얻기 위해 다른 필터링을 사용합니다. select * from foo에 해당하는 작업을 수행 할 수 있지만 그 모드에서는 멈추지 않습니다. 말했다

, 음속는 않습니다 - 직접 테이블/뷰 액세스 상자에서 사용할 때 - 가 상황에 따라 단점이 될 수있는 전체 행을 아래로 가져. 그러나 저장된 procs를 통한 액세스는 문제가 아닙니다. 다른 사람들과 이야기 할 수는 없지만 SubSonic은 모든 procs을 캡슐화하는 SPs 클래스를 유용하게 생성하여 메소드로 호출하고 적절한 DataTable을 반환 할 수 있습니다. 그런 다음 필요에 따라 수동으로 구문 분석 할 수 있습니다. 또한 procs에서 DAL 클래스 목록을 초기화하는 방법이 있으므로 proc이 테이블/뷰와 직접적으로 일치하는 데이터 세트를 반환하면 직접 처리하지 않고도 더 명확한 구문을 사용할 수 있습니다.

(SubSonic, 모든면에서 "procs"를 치료했습니다.) 저는 지금 일반적으로 CRUD procs를 수행하는 데 거의 시간을 들이지 않고 과거와 마찬가지로 복잡한보고를 위해 사용합니다. 귀하의 마일리지가 실제로 달라질 수 있습니다.)

Answer 3

SubSonic은 저자 중 한 사람인 Rob Connery에 따르면 신속한 응용 프로그램 개발을 지원하고 대규모 응용 프로그램에 대해서는 적게 작성되었습니다. 난 당신이 지역 사회에서 가장 많은 지원을 찾을거야 마찬가지로 NHibernate 가서 테스트를 거친 진정한 프레임 워크를 말할 것입니다. NHibernate 설정에 대한 정보는 www.dimecasts.net에서 얻을 수 있습니다.

Answer 4

기존의 저장된 procs에 액세스하는 데 필요한 모든 코드를 생성하려면 SubSonic을 사용하는 것이 좋습니다. 이렇게하면 새 데이터 액세스 레이어로 인해 회귀 가능성이 줄어 듭니다. 모든 새 기능은 SubSonic에서 생성 한 ActiveRecord 클래스를 사용하여 액세스 할 수 있습니다. 이것은 나에게 가장 안전하고 빠른 접근 방법이 될 것 같습니다.

저장 프로 시저 작업에 적합하지 않기 때문에 NHibernate 권장 사항에 동의하지 않습니다.

Answer 5

우리는 엔티티 프레임 워크를 orm으로 사용하려고 시도했으며 도메인 기반 개발과 함께 사용할 때 여러 가지 문제가 발생했습니다. SQL에 Linq도 몇 가지 한계가 있으며 다음 릴리스에서 Microsoft가 지원을 중단 할 것이라고 믿습니다.

Answer 6

쿼리가 저장 프로 시저에 있으면 이미 잘 최적화 된 가능성이 있습니다. 그리고 아마 그들은 내가 도전이 될 것으로 예상 것 인 ORM 형 추상화 계층으로, 정확하게을 위해 조인 SQL 식, 서브 쿼리 등

효율성과 표현의 종류를 복제의 자유로운 사용을 - 특히 만약 ' 다시 도구에 익숙하지 않아야합니다.

나머지 앱을 똑바로 처리하면 항상 리팩터링 할 수 있습니다. 그리고 ORM 세계는 충분히 빠르게 변화하고있어 여러분이 거기에 도착했을 때 옵션이 분명히 다를 것입니다.