2010-09-21 66 views
11

Cách tiếp cận tốt nhất để triển khai CRUD trên giao diện BL sử dụng giao diện DAL là gì? Tôi cần kẻ ý kiến ​​của bạn ..Thực hiện CRUD bằng Giao diện

Đây là dự thảo của tôi ..

Đối tượng dữ liệu được ánh xạ trong bảng cơ sở dữ liệu

public class Student 
{ 
    public string StudentId { get; set; } 
    public string StudentName { get; set; } 
    public Course StudentCourse { get; set; } 
} 

public class Course 
{ 
    public string CourseCode { get; set; } 
    public string CourseDesc { get; set; } 
} 

Tôi tạo ra một giao diện CRUD đến hoạt động của đối tượng trừu tượng

public interface IMaintanable<T> 
{ 
    void Create(T obj); 
    T Retrieve(string key); 
    void Update(string key); 
    void Delete(string key); 
} 

Sau đó, một thành phần quản lý Thực thể và các hoạt động của nó bằng cách triển khai giao diện

public class StudentManager : IMaintainable<Student> 
{ 
    public void Create(Student obj) 
    { 
     // inserts record in the DB via DAL 
    } 

    public Student Retrieve(string userId) 
    { 
     // retrieveds record from the DB via DAL 
    } 

    public void Update() 
    { 
     // should update the record in the DB 
    } 

    public void Delete(string userId) 
    { 
     // deletes record from the DB 
    } 
} 

sử dụng mẫu

public void Button_SaveStudent(Event args, object sender) 
    { 
     Student student = new Student() 
     { 
      StudentId = "1", StudentName = "Cnillincy" 
     } 

     new StudentManager().Create(student); 
    } 

như bạn có thể thấy, có khá một bất thường về phương pháp cập nhật

public void Update() 
    { 
     // should update the record in the DB 
    } 

gì nên phương pháp này phải cập nhật các đối tượng sở hữu? tôi có nên kế thừa Sinh viên không?

public class StudentManager : Student , IMaintainable<Student> 
    { 
     public void Update() 
     { 
      //update record via DAL 
     } 
    } 


    public void Button_SaveStudent(Event args, object sender) 
    { 
     Student student = new StudentManager(); 
     student.StudentId = "1"; 
     student.StudentName = "Cnillincy" 
     student.Update() 
    } 

Hoặc tôi chỉ nên chứa lớp Sinh viên làm thuộc tính của Người quản lý sinh viên?

 public class StudentManager : IMaintainable<Student> 
    { 
     public Student student { get; private set }; 

     public void Create() {} 
     public void Update() {} 
     public void Retrieve() {} 
     public void Delete() {} 
    } 

Điều gì phù hợp hơn? Còn giao diện thì sao? Bất kỳ kẻ đề xuất nào khác? thanks..C

Trả lời

14

giao diện CRUD của bạn có thể sẽ giống như

public interface IMaintanable<T> 
{ 
    string Create(T obj); 
    T Retrieve(string key); 
    void Update(T obj); 
    void Delete(string key); 
} 

có nghĩa là, cả hai CreateUpdate lấy một bản sao của đối tượng bạn đang cập nhật. Sự khác biệt là Update có thể lấy số key từ số obj, do đó, nó biết đối tượng nào đang thay đổi. Create thường sẽ tạo khóa được tạo để bạn trả lại khóa dưới dạng giá trị trả về. Hy vọng rằng sẽ giúp.

(The Update cũng có thể vượt qua trở lại chìa khóa quá.)

+0

bạn có nghĩ nó hiệu quả hơn kế thừa đối tượng không, vì nó có nghĩa là bạn sẽ tạo một bản sao khác của obj thay vì chỉ cập nhật nó, – CSharpNoob

+2

Thừa kế sẽ không có ý nghĩa. Sinh viên của bạn KHÔNG PHẢI là sinh viên. – Matthieu

+0

Điều Matthieu nói. Hãy suy nghĩ của học sinh như một hồ sơ và StudentManager của bạn giống như thư ký hiệu trưởng, gõ các hồ sơ lên ​​khi họ bước vào. Nguyên tắc trách nhiệm duy nhất FTW. – Lunivore

0

tôi sẽ không làm StudentManager kế thừa sinh viên, tôi sẽ làm cho phương thức Update của tôi không quốc tịch như tạo phương pháp của bạn, ví dụ:

public interface IMaintanable<T> 
{ 
    void Create(T obj); 
    T Retrieve(string key); 
    void Update(T obj); 
    void Delete(string key); 
} 

public void Update(T obj) 
{ 
    // should update the record in the DB 
} 
+2

bạn có thể giải thích tại sao điều này thích hợp hơn là kế thừa hoặc phân bổ Dữ liệu không? cảm ơn – CSharpNoob

+1

Đối với tôi, nó trở thành "sự chính xác" và sự lo ngại về sự lo lắng của OO; Một StudentManager không phải là một Sinh viên (theo nghĩa OO). Trách nhiệm của các sinh viên là mô hình hóa dữ liệu, trách nhiệm của StudentManagers là duy trì dữ liệu đó, tôi chỉ nghĩ rằng những dữ liệu đó không nên trộn lẫn. Nhưng đó chỉ là ý kiến ​​của tôi, tôi có thể không đúng :) – JonoW

2

Tôi thấy điều này từ Rob Conery mà tôi thực sự thích. Sức mạnh của nó là sự linh hoạt của các đối số mà bạn có thể chuyển cho các phương thức. Hàm ý của bạn không phải là IMO đủ mạnh. Kiểm tra bộ khởi động MVC của mình ở đây http://mvcstarter.codeplex.com/ (Nó được gọi là ISession có).

public interface IMaintainable : IDisposable 
    { 
     T Single<T>(Expression<Func<T, bool>> expression) where T : class, new(); 
     System.Linq.IQueryable<T> All<T>() where T : class, new(); 
     void Add<T>(T item) where T : class, new(); 
     void Update<T>(T item) where T : class, new(); 
     void Delete<T>(T item) where T : class, new(); 
     void Delete<T>(Expression<Func<T, bool>> expression) where T : class, new(); 
     void DeleteAll<T>() where T : class, IEntity, new(); 
     void CommitChanges(); 
    } 
+0

điều này giống như IEnumerable phương pháp mở rộng .. cảm ơn – CSharpNoob

+0

Không phải lo lắng ... Một khi bạn có một cái nhìn tại giải pháp của mình bạn sẽ thấy ít mã bạn thực sự cần phải làm hầu hết các hoạt động CRUD. –

+0

@JamesSouth nhận lỗi trên từ khóa IEntity –

9

Cá nhân, tôi nghĩ rằng tất cả những gì bạn đang thiếu là thuật ngữ thích hợp. Điều này thực sự là một xấp xỉ của một mô hình rất hữu ích, được gọi là mô hình kho lưu trữ.Theo như nhận thức kiểu, đi, việc thực hiện sẽ được gọi là một kho lưu trữ chung.

Cách tôi đã thực hiện cá nhân trong quá khứ là có giao diện xác định kho lưu trữ, chẳng hạn như IRepository<T> và lớp cơ sở dành riêng cho loại kho lưu trữ, chẳng hạn như SqlRepositoryBase<T>. Lý do mà tôi sẽ làm điều này là tôi có thể đặt mã thực hiện cụ thể trong lớp cơ sở. Vì vậy, hệ thống ống nước được thực hiện và tôi có thể lo lắng về việc triển khai miền cụ thể trong kho cuối cùng, sẽ là StudentRepository, SqlRepository<Student> (hoặc SqlRepository<IStudent> nếu bạn xác định giao diện cho thực thể của mình).

Có vẻ như bạn đang lo lắng về việc có bao nhiêu đối tượng được instansiated, và tôi có thể nói với bạn rằng bạn không tạo ra một cống đủ quan trọng về tài nguyên để thực sự quan tâm đến việc thực hiện trong thời trang này. Các bộ hẹn giờ cũ có thể bị xáo trộn ở thực tế, nhưng chúng tôi không cố gắng tối ưu hóa cho 64k hoặc RAM nữa. ;-) Đó là thêm về bảo trì, hợp đồng mã, v.v.

Không thêm sự phức tạp không cần thiết, nhưng bạn cũng có thể muốn xem xét Mẫu đơn vị công việc nếu bạn đang tìm kiếm nhiều thực thể khác nhau các loại giao dịch nguyên tử.

Dưới đây là một vài tài liệu tham khảo tốt cho các chủ đề này:

Hai takeaways từ này nói chung (IMHO):

  • tôi cá nhân không đồng ý với giả định rằng một patt Repository Cách tiếp cận ern chỉ có ích trong các dự án lớn hơn; đặc biệt là mẫu Repository chung. Nếu bạn bắt đầu đặt mã như thế này vào một thư viện tái sử dụng, bạn sẽ ngạc nhiên về việc bạn có thể bắt đầu tạo ra một nguồn tài nguyên vô giá của các khối xây dựng như thế nào.

  • Điểm cộng lớn nhất từ ​​phương pháp này là khả năng thử nghiệm tuyệt đối của nó; thậm chí nhiều hơn so với khả năng sử dụng lại. Nếu bạn đang tìm cách để giả lập kho của bạn cho bất kỳ loại một cách tiếp cận TDD, bạn có thể làm như vậy với ít nỗ lực. Điều này sẽ cho phép bạn viết các bài kiểm tra phong phú hơn về việc sử dụng các kho lưu trữ trong suốt mã của bạn.

+1

Một mẫu CRUD như thế này về cơ bản là một mẫu kho lưu trữ, dù bạn có thể gọi nó là gì. Tôi đồng ý với nhận xét của bạn về việc nó hữu ích ngay cả đối với các dự án nhỏ. Điều tốt về việc tiếp cận nó từ quan điểm của CRUD là nó dịch thực sự độc đáo đối với REST. REST, thậm chí được thực hiện kém, là khá performant và khả năng mở rộng. Với một tên miền như sinh viên - được truy cập rất nhiều chỉ trong vài ngày mỗi năm - hiệu suất thực sự có thể là một cân nhắc, ngay cả khi nó không phải là một người khác biệt. – Lunivore

+0

Joseph, năm sau vẫn còn giá trị, như vậy liên kết cho "Đơn vị công việc mẫu" bị hỏng, bạn có thể cập nhật điều này? – Edward

+0

@Edward - done. Đã sử dụng Máy Wayback để kéo lưu trữ của nó. Cảm ơn! –

0

Hãy xem Entity Framework 4 mới được phát hành gần đây. Chúng có tính năng mô hình "mã theo quy ước" cho phép bạn dễ dàng ánh xạ các đối tượng kinh doanh trực tiếp tới cơ sở dữ liệu mà không phải lo lắng về DAL.

"The Gu" có great series phác thảo cách dễ dàng để ánh xạ đối tượng của bạn và thậm chí thực hiện một số sửa đổi đơn giản khi liên kết với cơ sở dữ liệu thông qua mô hình DbContext mà nó sử dụng.

Điều đáng lưu ý là bản phát hành hiện tại là tại CTP4, nhưng tôi dự đoán hầu hết các vấn đề đã được làm việc với khung và sẽ phục vụ bạn tốt.

0

Tôi đã thay đổi câu trả lời ở đây một chút, như thế này:

public interface IMaintanable<T> 
{ 
    Guid Create(T obj); 
    T Read(Guid key); 
    bool Update(T obj); 
    bool Delete(Guid key); 
} 

Giao diện này được dựa trên cấu trúc cơ sở dữ liệu của tôi. Tôi sử dụng Hướng dẫn cho các khóa chính.

+1

Có thể tốt để giải thích lý do bạn đề xuất thay đổi ... –

Các vấn đề liên quan