미래 보장 DAL

Question

우리는 몇 가지 하위 프로젝트가 포함 된 정말 긴 개발 프로젝트의 시작입니다. 기본적으로 각 하위 프로젝트는 개발하는 데 몇 개월이 걸릴 것입니다. 코드 자체는 여러 개의 C# 프로젝트로 분할되지만 실제 데이터베이스는 모든 프로젝트에서 공유됩니다.

문제는 유지 관리 가능성입니다. 테이블에 열을 추가하거나 테이블을 두 개의 작은 테이블로 분할하면 이러한 변경을 지원하기 위해 C# DAL을 수정해야합니다. 이는 단일 프로그램의 요구 만이 아니라 회사 전체의 요구 사항에 따라 DB를 지속적으로 적용 할 것이기 때문에 허용되지 않습니다. 끊임없이 변화하는 오래된 코드는 새벽 작업이 될 것입니다.

DB 사람들은 다른 견해를 제시했습니다. 저장 프로 시저를 통해 모든 CRUD를 수행하고 여러 테이블에서 Linq를 사용하여 SELECT 문을 수행합니다. 그런 다음 몇 년 후 DB를 재구성하면 동일한 저장된 procs와 views를 제공 할 수 있으며 이전 코드를 수정할 필요가 없습니다.

우리가 갖고있는 질문은 이와 같은 이유로 ORM을 사용해야하는 이유는 무엇입니까? EF는 조금 지나친 것 같습니다 (아마도 그렇지 않을 수도 있습니다). 그것과 함께 SubSonic과 같은 것이 T4 templating이 simpiler (그리고 아마도 더 빠른) DAL을 허용합니까?

또는 누군가이 전체 프로세스를 덜 고통스럽게 만드는 방법에 대한 아이디어가 있습니까? 응용 프로그램에 다른 레이어를 추가하지는 않겠지 만 db 변경 시마다 코드를 수정하고 다시 돌아가고 싶지 않습니다.

편집 1 : 그래서 "나는 더 많은 레이어를 추가하고 싶지 않습니다."라고 말했을 때. 이것은 우리가 이미 여러 개의 레이어를 가지고 있기 때문에 주로 발생합니다. 우리는 Silverlight 뷰, 뷰 모델, BLL 객체 (CSLA를 통해)를 가지고 있고, DAL을 가지고 있으며, 마지막으로 SQL 테이블을 가지고 있습니다.

Answer 1

C# DAL... not just the needs of a single program.C# DAL의 핵심은 별도의 어셈블리로서 모든 유형의 .NET 응용 프로그램에서 다시 사용할 수 있다는 것입니다. 가장 큰 문제는 데이터베이스가 변경되면 DAL을 변경해야하고 (한 번) DAL에 종속 된 모든 응용 프로그램을 새 DAL로 다시 배포해야한다는 것입니다. 또한 비 닷넷 응용 프로그램에서 DAL을 사용할 수 없다는 문제점이 있습니다.

그렇다면 모든 응용 프로그램에 대해 다시 배포 할 필요가 없도록 DAL을 중앙화하려면 어떻게해야합니까? SOA를 생각하십시오. DAL (및 아마도 BLL)을 포함하도록 WCF 서비스를 작성할 수 있습니다. 모든 응용 프로그램 (.NET이 아닌 웹 서비스를 사용하는 경우)은이 서비스를 사용할 수 있습니다. 데이터베이스가 변경되면 WCF 서비스를 업데이트하고 한 번 배포합니다. 다만 당신이 어떤 급격한 변화도하지 않는다는 것을 확인하십시오! 기능을 추가/변경해야하는 경우 MyMethod2를 만듭니다.

참고 : 프리젠 테이션 (UI), 응용 프로그램 (당신의 BLL/DAL : 당신은 n 계층을들을 때, 보통 는 각 계층 별도의 소프트웨어 및 보통 별도의 서버에있는 3 층을 말한다), 데이터 (귀하의 SQL 데이터베이스). 이 아키텍처에는 장점이 있습니다.

We'd rather not add another layer to our application. 좋아요, 그래서 3-tier가 당신의 경우에 가장 좋은 방법이 아닐 수도 있습니다.

neither do we want to go back and modify code everytime we make a db change 그러면 DBA 사람들이 제안한 것이 유일한 방법입니다.

그러나 다음을 고려하십시오. 저장 프로 시저가 코드 수정과 동일합니까? 기본적으로 같은 것입니다. SQL 저장 프로 시저는 종종 버전 제어되거나 테스트되지 않지만 반드시 있어야합니다. SQL에는 .NET과 같은 풍부한 언어가 없습니다. WCF는 웹 팜에서 쉽게 확장 할 수 있습니다. 이러한 이유와 다른 이유를 고려한 후에는 3-tier/SOA 방식으로 전환하는 것이 좋습니다.

정말 프로젝트의 크기, 직원의 기술, 미래 성장 등에 달려 있으며, 이는 사용자가 결정할 수있는 것입니다.

Answer 2

나는이 적용 속성 몇 가지 방법을, 당신은 간단한 클래스 파일에서 해당 모델을 정의 할 수 있습니다 http://ormeter.net/

에서 성능 정보를 기반으로 BLToolkit을 사용하여 추가하기 시작하고 당신이 DAL를 프레스토있다. 테이블을 두 개로 분할하고 원래 테이블을 유지하면서 새 테이블을 작성하여 분할 테이블을 지원할 수 있습니다. 그냥 당신이 만드는 모든 방법을 안타 테스트 프로젝트를 만들 수 있는지 확인해야합니다 그들은 각 릴리스

클래스와 모든 작업

public class DirectoryListing 
    { 
     [PrimaryKey, Identity] 
     public Int64 Id { get; set; } 
     public Int64? OldId { get; set; } 
     public Int32 CategoryId { get; set; } 
     [Nullable] 
     public String CompanyName { get; set; } 
} 

일반 선택 또는 테이블 반환 함수 :

[SqlQuery("SELECT * FROM Ajax_CategorySearch(@SearchString, @ResultCount)")] 
[Cache(MaxCacheTime = 10, IsWeak = false)] 
public abstract List<String> AjaxCategorySearch(String @SearchString, Int32 @ResultCount = 10); 

또는 사용하기 저장된 프로 시저 :

[ActionName("SelectById")] 
public abstract Model.DirectoryListing SelectById(Int64 @Id); 

이렇게하면 SP DirectoryListing_SelectBy 더 고전적인 방법으로 아이디

아, 그리고하고있는 일이 너무

using (BIFDbManager db = new BIFDbManager()) 
    { 
     var output = db.SetCommand(
      "SQL GOES HERE", 
      db.Parameter("@Id", 1)) 
      .ExecuteList<DAL.Model.DirectoryListing>(); 

     totalrecords = output.Count(); 

     return output; 
    } 

퍼즐의 마지막 조각은 또한 LINQ 지원을 가능하게하는 DB 관리자입니다 쉽다.

public class BIFDbManager : DbManager 
{ 
    public BIFDbManager() : base("Connection string name") { } 

    public Table<DirectoryListing> DirectoryListings { get { return GetTable<DirectoryListing>(); } } 
} 

Answer 3

데이터베이스없이 얼마나 오래 일할 수 있습니까? 그것이 문제라면, 늦게 소개하십시오. 그리고 예, 아마도 레이어를 추가한다는 의미입니다.