Thảo Trịnh -
  • Chuyện đọc
  • Lập trình
    • Học nghề
    • Làm thợ
    • Agile Mindset
      • Agile Project Management (APM)
      • Tư duy linh hoạt
  • Nói chuyện vui
Thảo Trịnh -
Chuyện đọc
Lập trình
    Học nghề
    Làm thợ
    Agile Mindset
    Agile Project Management (APM)
    Tư duy linh hoạt
Nói chuyện vui
  • Chuyện đọc
  • Lập trình
    • Học nghề
    • Làm thợ
    • Agile Mindset
      • Agile Project Management (APM)
      • Tư duy linh hoạt
  • Nói chuyện vui
Công nghệ

Unit of Work Design Pattern

Trong bài viết này, chúng ta sẽ cùng thảo luận về Unit of Work Design Pattern.

Nội dung chính:

  • Lợi ích khi sử dụng Unit of Work design pattern?
  • Work và Unit trong ứng dụng phần mềm.
  • Logical transaction! = Physical CRUD.
  • So sánh với một transaction.
  • Ý tưởng việc implement UOW.
  • Code demo C#

Lợi ích khi sử dụng Unit of Work design pattern?

Khái niệm UOW

  • First it maintains in-memory updates.
  • Second it sends these in-memory updates as one transaction to the database.

Giải thích

– Thứ 1: uow quản lý các trạng thái cập nhật dữ liệu trong bộ nhớ.

– Thứ 2: uow thực hiện cập nhật tất cả dữ liệu trong bộ nhớ “như là – một transaction” vào database.

Từ khái niệm trên, chúng ta rút ra được lợi ích khi sử dụng uow

  • Quản lý danh sách các đối tượng logic nghiệp vụ được thay đổi trong một transaction.
  • Khi một transaction được complete, tất cả thay đổi sẽ được gửi tới database như một big unit of work

Work và Unit trong ứng dụng phần mềm.

Một cách đơn giản để định nghĩa Work là: "Thực hiện một vài tác vụ". Các tác vụ ở đây có thể là Thêm, Sửa, Xóa dữ liệu.
Chúng ta có thể cùng xem một ví dụ về việc ứng dụng quản lý khách hàng. Khi chúng ta thêm/sửa/xóa khách hàng trong database, đó là một unit. Kịch bản đơn giản của chúng ta đó là:

1 customer CRUD = 1 unit of work

Logical transaction! = Physical CRUD

Trong bài toán thực tế, một khách hàng có thể có nhiều địa chỉ giao hàng khác nhau (địa chỉ nhà, địa chỉ cơ quan…).

Tiếp theo ví dụ trên, chúng ta xem xét ông khách hàng Shiv. Giả sử ông này có 2 địa chỉ, vậy khi thay đổi thông tin của khách hàng Shiv này, chúng ta cần thay đổi 3 bản ghi. Xem xét kịch bản như sau:

3 Customer CRUD = 1 Logical unit of work

Trong các dự án thực tế, chúng ta có thể đưa nhiều tác vụ khác nhau vào một unit of work.

Một ví dụ đơn giản khác, đó chính là bài toán rút tiền tại cây ATM. Khi khách hàng thực hiện rút tiền, ngân hàng cập nhật thông tin bảng giao dịch, cập nhật số dư khách hàng, gửi tin nhắn, in hóa đơn.. Tất cả các tác vụ đó có thể đưa vào một UOW

So sánh với simple transaction

Một UOW sẽ rất khác với một transaciton database. UOW chỉ gửi những bản ghi được thay đổi tới database mà không phải tất cả các bản ghi!

Điều này có nghĩa là gì?

Ví dụ ứng dụng của bạn lấy từ DB ra 3 bản ghi dữ liệu, nhưng chỉ thay đổi 2 trong 3 bản ghi đó. UOW chỉ gửi 2 bản ghi được thay đổi này tới DB để tiến hành cập nhật. Việc này giúp tối ưu performance cho hệ thống của bạn.

Tóm lại

1 Unit of work = Modified records in a transaction

Sample code for unit of work

Bước 1: Tạo Interface

Theo phần trước đã thảo luận, chúng ta biết rằng UOW theo dõi và quản lý những thay đổi trong các đối tượng nghiệp vụ.

Bây giờ hãy xem xét bài toán với rất nhiều các đối tượng nghiệp vụ với nhiều kiểu khác nhau. Ví dụ bạn có thể có customer, suplier, account…Các đối tượng này chính là các entities mà UOW quan tâm và xử lý.

Xem xét kiến trúc sau

Với thiết kế UOW tracking nhiều đối tượng, chúng ta có thể giảm thiểu rất nhiều số mã trùng lặp.

Đầu tiên chúng ta tạo interface IEntity  như sau:

public interface IEntity
{
    int Id { set; get; }
    void Insert();
    void Update();
    List<IEntity> Load();
}

Các đối tượng Customer, Supplier, Order sẽ implement interface này, theo kiến trúc đơn giản như sau:

Bước 2: Implement the IEntity interface

public class Customer : IEntity { private int _CustomerCode = 0; public int Id { get { return _CustomerCode; } set { _CustomerCode = value; } } private string _CustomerName = ""; public string CustomerName { get { return _CustomerName; } set { _CustomerName = value; } } public void Insert() { DataAccess obj = new DataAccess(); obj.InsertCustomer(_CustomerCode, CustomerName); } public List<IEntity> Load() { DataAccess obj = new DataAccess(); Customer o = new Customer(); SqlDataReader ds = obj.GetCustomer(Id); while (ds.Read()) { o.CustomerName = ds["CustomerName"].ToString(); } List<IEntity> Li = (new List<Customer>()).ToList<IEntity>(); Li.Add((IEntity) o); return Li; } public void Update() { DataAccess obj = new DataAccess(); obj.UpdateCustomer(_CustomerCode, CustomerName); } } Xem thêm

May 20, 2019by thaotrinh

Tìm kiếm

Tags

5whys Agile Apache blockchain C# CQRS Daily Scrum database DDD deadlocks Dependency Injection Dependency Inversion Design Pattern docker ebook git Good Developer growth mindset kinh tế Pair programing Repository Retrospective Risk Management Scrum Scrumban Scrum Guide Scrum Master Senior Senior Developer singleton solid sống Technical debt UI UnitOfWork UX Viết Động lực

Bài viết mới

Hãy agile đi

Hãy agile đi

Nói chuyện về vấn đề

Nói chuyện về vấn đề

Hỏi 5 lần tại sao

Hỏi 5 lần tại sao

Tư duy linh hoạt là gì

Tư duy linh hoạt là gì

Không phải làm bao nhiêu mà là tạo ra bao nhiêu

Không phải làm bao nhiêu mà là tạo ra bao nhiêu

Một cuộc đời đáng sống

Một cuộc đời đáng sống

Chuyên mục

  • Chuyện đọc
  • Lập trình
    • Agile Mindset
      • Agile Project Management (APM)
      • Tư duy linh hoạt
    • Công nghệ
      • .NET
      • Blockchain
      • Database
    • Học nghề
    • Làm thợ
  • Uncategorized
    • Gã
    • Nói chuyện vui
    • Product
      • Design