Mối quan hệ giữa Kho lưu trữ và Đơn vị công việc


17

Tôi sẽ triển khai một kho lưu trữ và tôi muốn sử dụng mẫu UOW vì người tiêu dùng của kho lưu trữ có thể thực hiện một số thao tác và tôi muốn cam kết chúng ngay lập tức.

Sau khi đọc một số bài viết về vấn đề này, tôi vẫn không biết làm thế nào để liên kết hai yếu tố này, tùy thuộc vào bài viết mà nó đang được thực hiện theo cách khác.

Đôi khi UOW là một cái gì đó bên trong kho lưu trữ:

public class Repository
{
    UnitOfWork _uow;

    public Repository()
    {
       _uow = IoC.Get<UnitOfWork>();
    }

    public void Save(Entity e)
    {
        _uow.Track(e);
    }

    public void SubmittChanges()
    {
        SaveInStorage(_uow.GetChanges());
    }
}

Và đôi khi nó là bên ngoài:

public class Repository
{
    public void Save(Entity e, UnitOfWork uow)
    {
        uow.Track(e);
    }

    public void SubmittChanges(UnitOfWork uow)
    {
        SaveInStorage(uow.GetChanges());
    }
}

Những lần khác, là UOW tham chiếu Kho lưu trữ

public class UnitOfWork
{
    Repository _repository;

    public UnitOfWork(Repository repository)
    {
       _repository = repository;
    }

    public void Save(Entity e)
    {
        this.Track(e);
    }

    public void SubmittChanges()
    {
       _repository.Save(this.GetChanges());
    }
}

Hai yếu tố này có liên quan như thế nào? UOW theo dõi các yếu tố cần thay đổi và kho chứa logic để duy trì các thay đổi đó, nhưng ... ai gọi ai? Liệu cuối cùng có ý nghĩa hơn?

Ngoài ra, ai quản lý kết nối? Nếu một số thao tác phải được thực hiện trong kho lưu trữ, tôi nghĩ rằng việc sử dụng cùng một kết nối và thậm chí giao dịch sẽ có âm thanh hơn, vì vậy có thể đặt đối tượng kết nối bên trong UOW và điều này cũng nằm trong kho lưu trữ.

Chúc mừng


Câu trả lời:


7

Re: "UOW theo dõi các yếu tố cần thay đổi và kho chứa logic để duy trì các thay đổi đó, nhưng ... ai gọi ai?"

Bạn hiểu trách nhiệm cơ bản của các lớp này. Bạn nói rằng mỗi bài viết mà bạn đã đọc sẽ kết nối chúng với nhau theo những cách khác nhau. Điều này ngụ ý rằng quyết định về "ai gọi ai" là tùy thuộc vào bạn.

Tôi sẽ cố gắng phác thảo vấn đề theo các 'lớp' trong khi được hướng dẫn bởi các hiệu trưởng cơ bản của thiết kế phần mềm tốt như Sự gắn kết , tách rời , Khả năng sử dụng lại , Khả năng kiểm tra đơn vị, v.v.

Để trích dẫn Eric Evans Domain Driven Design, (2004) Addison Wesley, trang 69 :

Hiệu trưởng cơ bản [của Kiến trúc phân lớp] là bất kỳ phần tử nào của lớp chỉ phụ thuộc vào các phần tử khác trong cùng lớp hoặc vào các phần tử của lớp "bên dưới" nó.

Theo tôi, cả UOW và Repo là hai lớp rất khác nhau có trách nhiệm rõ ràng, độc lập. Để bắt đầu, tôi sẽ không gọi người khác.

Tôi nghĩ rằng bạn cần một số lớp khách hàng thứ ba (tức là một controllerhoặc service class) thực sự biết 'khi nào và cái gì sẽ nhận được' từ repo và 'khi nào' để lưu giao dịch. Khách hàng này ngồi tương đối cao trong kiến ​​trúc (vì vậy có thể biết về nhiều lớp hơn) và có thể thực hiện một số phối hợp giữa hai lớp.

--------------------------------

         [Client]
           /   \
----------/---- \---------------
         /       \
        V         V
[Unit Of Work]  [Repo]


--------------------------------

2

Các phương thức thường được đưa ra nhất cho giao diện UOW (thường được xây dựng thông qua một nhà máy).

Bạn thường gọi các phương thức trên giao diện UOW từ lớp mẫu (es) / mặt tiền. Vì UOW chỉ đơn giản là trì hoãn IO cơ sở dữ liệu cho đến sau này (để ngăn bạn thực hiện các giao dịch dài hạn hoặc nhiều cuộc gọi đến cơ sở dữ liệu có thể không cần thiết), nên làm việc với UOW sẽ ở cùng mức mà bạn thường làm việc với cơ sở dữ liệu của mình.

Microsoft có một bài viết rất kỹ lưỡng về mẫu UOW:

http://msdn.microsoft.com/en-us/magazine/dd882510.aspx

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.