DALs tương lai bằng chứng

Question

Chúng tôi đang ở đầu của một dự án phát triển thực sự dài với một số dự án phụ. Về cơ bản mỗi tiểu dự án sẽ mất vài tháng để phát triển. Bản thân mã sẽ được chia thành nhiều dự án C#, nhưng cơ sở dữ liệu vật lý sẽ được chia sẻ bởi tất cả các dự án.

Sự cố là khả năng bảo trì. Nếu chúng ta thêm một cột vào một bảng, hoặc chia một bảng thành hai bảng nhỏ hơn, chúng ta sẽ phải quay lại và sửa đổi C# DAL của chúng ta để hỗ trợ những thay đổi này. Điều này là không thể chấp nhận được, vì chúng tôi sẽ liên tục điều chỉnh DB phù hợp với nhu cầu của toàn bộ công ty, và không chỉ là nhu cầu của một chương trình đơn lẻ. Liên tục thay đổi mã cũ sẽ là một nhiệm vụ không bao giờ hết.

Những người DB của chúng tôi đã đề xuất một chế độ xem khác. Chúng tôi làm tất cả CRUD của chúng tôi thông qua các thủ tục được lưu trữ và sử dụng LINQ trên nhiều bảng để thực hiện các câu lệnh SELECT của chúng tôi. Sau đó, nếu chúng ta tái cấu trúc DB vài năm kể từ bây giờ, chúng ta có thể đơn giản cung cấp cùng một procs được lưu trữ và các khung nhìn và không phải sửa đổi mã cũ của chúng ta.

Câu hỏi chúng tôi có, là những gì ORM nên được sử dụng cho một cái gì đó như thế này? EF có vẻ hơi quá mức (có thể là không). Sẽ có một cái gì đó giống như SubSonic với nó là khuôn mẫu T4 cho phép một Dp simpiler (và có lẽ nhanh hơn)?

Hoặc có lẽ ai đó có ý tưởng về cách làm cho toàn bộ quá trình này ít đau đớn hơn? Chúng tôi không muốn thêm một lớp khác vào ứng dụng của chúng tôi, nhưng chúng tôi cũng không muốn quay lại và sửa đổi mã mỗi lần chúng tôi thực hiện thay đổi db.

Chỉnh sửa 1: Vì vậy, khi tôi nói "Tôi không thực sự muốn thêm các lớp khác". Điều này chủ yếu là vì chúng tôi đã có nhiều lớp. Chúng ta có các khung nhìn Silverlight, các mô hình khung nhìn, các đối tượng BLL (thông qua CSLA) sau đó chúng ta có DAL, và cuối cùng là các bảng SQL mà chúng có.

Answer 1

C# DAL... not just the needs of a single program.Toàn bộ điểm của C# DAL như một assembly riêng biệt là nó có thể được tái sử dụng trên bất kỳ loại ứng dụng .NET nào. Vấn đề chính bạn gặp phải là nếu cơ sở dữ liệu thay đổi, thì DAL phải thay đổi (một lần), thì tất cả các ứng dụng phụ thuộc vào DAL phải được triển khai lại với DAL mới. Bạn cũng có vấn đề là DAL không thể được sử dụng bởi các ứng dụng không phải NET.

Ok, vậy làm thế nào bạn có thể tập trung DAL để bạn không phải triển khai lại nó cho mọi ứng dụng? Hãy suy nghĩ SOA. Bạn có thể xây dựng một dịch vụ WCF để chứa DAL (và có thể là BLL). Tất cả các ứng dụng của bạn (nếu bạn sử dụng các dịch vụ web, ngay cả những ứng dụng không phải là .NET) đều có thể sử dụng dịch vụ này. Khi cơ sở dữ liệu thay đổi, bạn cập nhật dịch vụ WCF của bạn và triển khai một lần. Chỉ cần chắc chắn rằng bạn không thực hiện bất kỳ thay đổi đột phá nào! Tạo một MyMethod2 nếu bạn cần thêm/thay đổi chức năng.

Lưu ý: Khi bạn nghe n-tier, nó thường đề cập đến ba tầng, trong đó mỗi tầng là phần mềm riêng biệt và thường trên máy chủ riêng biệt: trình bày (UI), ứng dụng (bạn BLL/DAL), dữ liệu ( cơ sở dữ liệu SQL của bạn). Có công đức cho kiến ​​trúc này.

We'd rather not add another layer to our application. Ok, do đó, ba tầng có thể không phải là cách tiếp cận tốt nhất trong trường hợp của bạn.

neither do we want to go back and modify code everytime we make a db change Sau đó, những gì người DBA của bạn đề xuất là cách duy nhất.

Tuy nhiên, hãy xem xét việc này: đang thay đổi quy trình được lưu trữ giống như sửa đổi mã? Về cơ bản nó cũng giống như vậy. Các thủ tục được lưu trữ SQL thường không được kiểm soát hoặc kiểm tra phiên bản, nhưng chúng nên. SQL không có sự phong phú của một ngôn ngữ như .NET. WCF có thể dễ dàng được thu nhỏ trong một trang trại. Một khi bạn đã xác định được những lý do này và các lý do khác, nó có thể đáng để thực hiện phương pháp tiếp cận ba tầng/SOA.

Nó thực sự phụ thuộc vào quy mô dự án của bạn, kỹ năng của nhân viên, tăng trưởng trong tương lai, v.v ... và đó là điều mà bạn chỉ có thể xác định.

Answer 2

Tôi đã bắt đầu sử dụng BLToolkit dựa trên các thông tin hiệu suất từ ​​http://ormeter.net/

Bạn có thể xác định mô hình của bạn trong các tập tin lớp học đơn giản, thêm một số phương pháp với các thuộc tính được áp dụng và Presto bạn có một Dal. Chia một bảng thành hai và bạn có thể duy trì tệp lớp gốc khi tạo tệp mới để hỗ trợ các bảng phân tách. Chỉ cần chắc chắn rằng bạn tạo một dự án thử nghiệm mà lượt truy cập mọi phương pháp để đảm bảo tất cả đều làm việc với mỗi bản phát hành

Lớp

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; } 
} 

chung chọn hoặc bảng chức năng có giá trị:

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

Hoặc sử dụng a proc được lưu trữ:

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

Điều này sẽ gọi SP DirectoryListing_SelectBy Id

Oh, và những thứ làm theo một cách cổ điển hơn là quá dễ dàng

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; 
    } 

Các mảnh cuối cùng của câu đố là người quản lý db, mà còn cho phép hỗ trợ LINQ.

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

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

Answer 3

Bạn có thể làm việc mà không có cơ sở dữ liệu trong bao lâu? Nếu nó là một vấn đề, hãy giới thiệu nó muộn. Và có, điều đó có nghĩa là bạn thêm một lớp.