Khung thực thể và tách lớp


12

Tôi đang cố gắng làm việc một chút với Entity Framework và tôi có một câu hỏi liên quan đến việc tách các lớp.

Tôi thường sử dụng UI -> BLL -> DAL và tôi tự hỏi làm thế nào để sử dụng EF ở đây.

DAL của tôi thường sẽ giống như

GetPerson(id)
{
    // some sql
    return new Person(...)
}

BLL:

GetPerson(id)
{
    Return personDL.GetPerson(id)
}

UI:

Person p = personBL.GetPerson(id)

Câu hỏi của tôi bây giờ là: vì EF tạo ra mô hình của tôi và DAL, đó có phải là một ý tưởng tốt để bọc EF trong DAL của riêng tôi hay nó chỉ là một sự lãng phí thời gian?

Nếu tôi không cần phải bọc EF, tôi vẫn sẽ đặt Model.esmx của mình trong thư viện lớp của chính nó hay sẽ ổn nếu chỉ đặt nó bên trong BLL của tôi và làm việc ở đó?

Tôi thực sự không thể thấy lý do để bọc EF trong DAL của riêng mình nhưng tôi muốn biết những gì người khác đang làm.

Vì vậy, thay vì có những điều trên, tôi sẽ bỏ DAL và chỉ làm:

BLL:

GetPerson(id)
{
    using (TestEntities context = new TestEntities())
    {
            var result = from p in context.Persons.Where(p => p.Id = id)            
                    select p;
    }
}

Phải làm sao

Câu trả lời:


13

Ví dụ bạn cung cấp là kiến ​​trúc lớp khó. Tôi biết nó được cố ý đơn giản hóa, nhưng:

Lớp trình bày của bạn được gắn trực tiếp với thực thể Person. Điều này chỉ ổn trong những trường hợp đơn giản nhất và chắc chắn không phải khi bạn đang cố gắng xác định các lớp của mình.

Phương thức GetPerson cũng đang sử dụng một thực tiễn khá tệ là tạo bối cảnh mới cho mỗi cuộc gọi. Bạn sẽ nhận được bối cảnh trong hàm tạo và nó sẽ được cung cấp bởi bộ chứa IOC của bạn.

Một cấu trúc đơn giản nhưng hiệu quả mà tôi đã sử dụng là:

  • Project.Core - chứa các mô hình và giao diện xem.
  • Project.DAL - với EDMX của tôi và mã được tạo.
  • Project.BLL - logic kinh doanh.
  • Project.Web - chính ứng dụng web.

Điều quan trọng cần lưu ý là:

  • Core không phụ thuộc vào bất kỳ giải pháp nào khác.
  • DAL không phụ thuộc vào bất kỳ giải pháp nào khác.
  • Project.Web phụ thuộc vào Core, nhưng không phụ thuộc vào DAL cũng như BLL.
  • BLL phụ thuộc vào Core và DAL.

1
Core sẽ xuất hiện là một lớp đối tượng kinh doanh.
sq33G

Đây cũng là thứ tôi sử dụng khá nhiều, tuy nhiên, tôi sẽ thêm các DLL bổ sung để phục vụ cho việc khai báo giao diện. Bằng cách này, bạn chỉ tham chiếu các giao diện (và sử dụng một cái gì đó như [url = unity.codeplex.com/[Unity[/url] cho DI) và bạn có thể chắc chắn rằng không có sự phụ thuộc kỳ lạ nào mà bạn vô tình gây ra.
Ed James

Thông thường, không có EF tôi tạo lớp Person của riêng mình trong lớp "Model", vì vậy tôi có UI, BLL, DAL và Model trong đó: UI biết BLL và Model. BLL biết DAL và Model. DLL biết Model. Bạn có tạo "mô hình xem" của riêng mình không và tại sao bạn không sử dụng những cái mà EF tạo ra? (tôi biết điều này đi ngược lại với kiến ​​trúc phân lớp, nhưng bạn thực sự thay đổi cách bạn lấy dữ liệu bao nhiêu lần?)
Thomas

@Thomas gói các mô hình xem trong một cái gì đó trừu tượng sẽ làm cho việc kiểm tra đơn vị dễ dàng hơn nhiều.
sq33G

3
mô hình! = xem mô hình
Boris Yankov

2

Bạn không cần phải bọc EDMX của mình vào bất cứ điều gì.

Nếu bạn có thể thấy trước khả năng cần phải thay đổi từ EF sang một cách tiếp cận khác, bạn có thể muốn mở rộng các đối tượng kinh doanh của mình (tận dụng các lớp một phần) để triển khai các giao diện được xác định trong lớp Đối tượng kinh doanh riêng biệt.

Sau đó, từ mã của bạn, bạn sẽ chỉ xử lý các giao diện đó chứ không phải với các lớp được tạo cụ thể. Một ít mã keo có thể cần thiết để giữ điều này với nhau; với EDMX có thể là DAL của bạn.


Vì vậy, nếu tôi không từ bỏ bất kỳ thay đổi nào từ EF sang cách tiếp cận khác, mã của tôi ở trên sẽ ổn chứ? Sau đó tôi sẽ chỉ có UI và BLL (nơi EDMX nằm trong BLL)?
Thomas

Câu trả lời thực dụng của tôi sẽ là có. Với lời cảnh báo mà bạn thực sự có thể muốn đưa EDMX vào tổ hợp nhỏ của mình nếu nó sẽ lớn và chủ yếu là tĩnh, do đó bạn sẽ không cần phải biên dịch lại / phân phối lại thường xuyên.
sq33G

À, điểm hay về việc biên dịch lại / phân phối lại :)
Thomas

2

Có hai cách tiếp cận chung để xếp lớp: xếp lớp nghiêm ngặt và xếp lớp thoải mái.

Một cách tiếp cận phân lớp nghiêm ngặt ràng buộc các thành phần trong một lớp chỉ tương tác với các đồng nghiệp và với lớp ngay bên dưới.

Một ứng dụng lớp thoải mái nới lỏng các ràng buộc sao cho một thành phần có thể tương tác với các thành phần từ bất kỳ lớp thấp hơn.

Sử dụng phân lớp thoải mái có thể cải thiện hiệu quả vì hệ thống không phải chuyển tiếp các cuộc gọi đơn giản từ lớp này sang lớp kế tiếp. Mặt khác, sử dụng phân lớp thoải mái không cung cấp cùng một mức độ cách ly giữa các lớp và làm cho việc trao đổi một lớp thấp hơn mà không ảnh hưởng đến các lớp cao hơn.

Đối với các giải pháp lớn liên quan đến nhiều thành phần phần mềm, thông thường có một số lượng lớn các thành phần có cùng mức độ trừu tượng không gắn kết. Trong trường hợp này, mỗi lớp có thể được phân tách thành một hoặc nhiều hệ thống con gắn kết. Hình 2 minh họa một ký hiệu Ngôn ngữ mô hình hóa thống nhất (UML) có thể để biểu diễn các lớp được tạo thành từ nhiều hệ thống con.

kết luận: nếu bạn không cần lớp giữa thì mất nó; không phải tất cả các ứng dụng yêu cầu cùng một cách tiếp cận và bằng cách nào đó thêm một lớp chỉ cho mục đích phân lớp sẽ có hình phạt về chi phí phức tạp và bảo trì.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.