Lập trình đôi (tiếng Anh: Pair Programming) là kiểu lập trình đòi hỏi hai kỹ sư phần mềm cùng tham gia một nỗ lực lập trình chung trên một máy trạm, nghĩa là chỉ có một màn hình, một bàn phím. Mỗi người thực hiện việc mà người kia hiện không làm. Ví dụ, người này gõ các bộ test đơn vị (unit test), người kia nghĩ về các lớp đầu vào (input) sẽ thỏa mãn bộ test đó; hoặc người này viết mã còn người kia quan sát để hướng dẫn hoặc kiểm lỗi. Người ta khuyên rằng hai người nên luân phiên đổi vai trò, khoảng nửa giờ một lần.

Ưu điểm:
Lập trình đôi được quảng cáo là đem lại các lợi ích sau (theo thứ tự từ lớn tới nhỏ):

• Tăng kỷ luật làm việc. Những người làm việc theo cặp thường có xu hướng “làm đúng” hơn và ít nghỉ giải lao dài.
• Mã chương trình tốt hơn. Những người làm việc theo cặp ít có xu hướng chọn giải pháp ngõ cụt mà thường cho ra các thiết kế với chất lượng cao hơn.
• Duy trì tốt luồng làm việc. Người này có thể người kia xem cả hai đang làm đến đâu. Nếu bị ngắt quãng, một người giải quyết ngắt quãng trong khi người kia tiếp tục làm việc.
• Nâng cao tinh thần. Với một số lập trình viên, làm việc theo cặp có thể vui vẻ hơn.
• Sở hữu tập thể đối với mã chương trình. Khi mọi người trong một dự án đều làm việc theo cặp, và các cặp thường xuyên quay vòng, thi ai cũng có kiến thức về toàn bộ mã nguồn.
• Cố vấn. Kể cả những lập trình viên mới vào nghề, người nào cũng biết một cái gì đó mà người khác không biết. Lập trình đôi là một cách nhẹ nhàng cho việc lan tỏa kiến thức đó.
• Gắn kết nhóm. Các thành viên trong nhóm gắn bó với nhau nhanh hơn khi làm việc theo cặp. Lập trình đôi có thể khuyến khích sự gắn bó trong nhóm.
• Ít ngắt quãng hơn. Người ta thường ngại làm đứt quãng một nhóm người (đôi) hơn là ngắt quãng một người đang làm việc một mình.
• Đòi hỏi ít máy trạm hơn, do hai người dùng chung một máy.

Khuyết điểm

• Các lập trình viên nhiều kinh nghiệm có thể cảm thấy nhàm chán khi hướng dẫn một lập trình viên ít kinh nghiệm trong một môi trường lập trình đôi.
• Nhiều kỹ sư thích làm việc một mình hơn, và có thể thấy môi trường lập trình đôi rất cồng kềnh.
• Khó so sánh được và mất giữa các môi trường đôi và không đôi, do các phương pháp đo năng suất lập trình viên còn đang gây nhiều tranh cãi.
• Các khác biệt trong phong cách viết mã có thể gây ra xung đột.
• Trong trường hợp các thành viên trong lập trình có lịch làm việc lệch nhau (điều thường thấy trong các môi trường coi trọng sự cân bằng giữa công việc và cuộc sống), thời gian làm việc theo cặp ít đi, dẫn tới việc tăng thời gian hoàn tất công việc.
• Khi một công ty đánh giá cao việc làm việc từ xa (làm việc tại nhà), hay khi một nhân viên phải làm việc tại nhà vì lý do nào đó, việc lập trình đôi có thể khó khăn hoặc không thể thực hiện được.
• Không hiểu ý nhau giữa 2 lập trình viên

Pair programing phù hợp lựa chọn khi nào?
– Pair programing thực sự phù hợp cho các dự án phức tạp, cần nhiều thời gian để làm quen, hiểu dự án. Khi đó có thể ghép cặp 1 thành viên mới và 1 thành viên có kinh nghiệm để vừa hoàn thành mục tiêu sản phẩm, vừa truyền đạt hiểu biết dự án.
- Trong trường hợp sự chênh lệnh về kĩ năng của các thành viên trong team sản phẩm là lớn, nhưng có nhu cầu transfer nhanh các kĩ thuật để làm việc.
– Trong các dự án refactor code, yêu cầu cao về coding convention, pair programing phát huy vai trò, khi luôn có 1 người giám sát thực hiện kĩ thuật.

Bài viết này chúng ta sẽ làm rõ các vấn đề
1. Technical debt là gì?
2. Khi nào gặp?
3. Phòng tránh và hạn chế như nào?
4. Làm sao để thay đổi?

Technical debt là gì? – Khi nào gặp?
Theo dịch thuật, technical debt có nghĩa là nợ kĩ thuật. Diễn giải ra, nợ kĩ thuật là khi vì tính chất, yêu cầu của dự án, khi code, chúng ta:
– Bỏ qua bước thiết kế hệ thống.
– Bỏ qua design pattern.
– Bỏ qua SOLID.
– Bỏ qua coding conventions.
– Thực hiện hotfix mà chưa đánh giá hết rủi ro.
– Nhằm đáp ứng yêu cầu về deadline, chọn giải pháp chưa thực sự tối ưu để giải quyết vấn đề.
– Copy paste thì nhanh hơn là refactor code.
Với khá nhiều “bỏ qua” và cách tiếp cận giải quyết bài toán như vậy. Dự án sẽ tồn đọng các vấn đề về kĩ thuật, lớn dần theo thời gian. Cho đến thời điểm, dự án sẽ lâm vào trạng thái sửa chữa, cập nhật thì mệt mỏi, đập đi xây lại thì không đủ nguồn lực, thời gian, kinh tế.

Phòng tránh, hạn chế bằng cách nào?
Ngoài các yếu tố phòng tránh về kĩ thuật. Developer hay Technical Leader cần có mindset về việc xử lý technical debt.
Mindset này thể hiện ở cách team tư duy về dự án. Luôn nhớ:
– refactor code ngay khi có thể.
– Chậm chắc, chuẩn chỉ, chỉn chu hơn là nhanh, tiềm ẩn rủi ro.
– Luôn có effort cho việc xử lý technical debt trong thời gian làm dự án.
– Quyết liệt với việc có sản phẩm tốt.

Vài lời chém gió, hi vọng mọi người khi làm dự án sẽ không bao giờ va phải dự án nào cần maintain mà có technical debt.

Xuất phát từ mấy vấn đề nên muốn cover lại kiến thức về static và singleton.

– Một là để hiểu rõ thêm vấn đề
– Hai là làm rõ thêm vấn đề

Vậy static có đặc điểm gì? Khi nào nên dùng nó?
Singleton thì sao? Dùng thế nào? Các vấn đề cần lưu ý khi sử dụng?

Ok, xắn ✋ vào tìm hiểu static trước.

Định nghĩa: một class static sẽ không cho bạn tạo một cài đặt. Nghĩa là bạn sẽ không thể sử dụng từ khoá new để tạo object. Muốn sử dụng methods và properties cần khai báo thêm từ khoá static và gọi trực tiếp bằng tên lớp.

Đặc điểm
– Có vùng nhớ riêng, không bị thay đổi.
– Chỉ có một refrence duy nhất trong ứng dụng.
– Do không thể tạo instantiated, nên không cần cấp phát thêm vùng nhớ.
– Life cycle giống application.
– Khởi tạo một lần duy nhất khi chạy chương trình.

Nên dùng khi nào
– Xây dựng các lớp không phụ thuộc vào object. Ví dụ class Utility, lưu các thông tin dùng chung cho toàn bộ ứng dụng.
– Tiết kiệm bộ nhớ.

Ok, giờ tới singleton.

Mình xin được copy lại góc nhìn của anh Hiền blog guru
Vì sao ra đời?
Trong GoF, Singleton được đưa ra với mục đích sau: “Ensure a class only has one instance, and provide a global point of access to it.” – “Đảm bảo một class chỉ có duy nhất một instance, và cung cấp một điểm truy cập duy nhất trên toàn cục tới instance.”

Lợi ích:
Nó cung cấp ý tưởng của việc một instance duy nhất, điều mà chúng ta gặp trong nhiều bài toán thực tế: một ứng dụng được khởi tạo, một cấu hình hệ thống, một logger…

Đặc điểm:
Về mặt runtime
– Tiết kiệm: Không giống như static trong class, object và các giá trị trong đó chỉ được khởi tạo khi cần thiết. Memory và cả CPU đều được tiết kiệm (static khởi tạo ngay khi chạy chương trình).
– Chủ động quản lý: Cho phép chủ động quản lý life cycle, giải phóng khi cần thiết.
Về mặt design
– Có khả năng thừa kế.
– Có thể kết hợp với các partern khác.
- Abstract hơn sử dụng static trong class.

Bàn thêm về singleton

Tư tưởng: giải quyết 2 bài toán khác nhau (dù có vẻ liên quan): “Ensure a class only has one instance, and provide a global point of access to it.”
– Một class có duy nhất một instance;
– Cung cấp một điểm truy cập duy nhất trên toàn cục tới instance.
– Tác giả đã vô tình kèm cả lời giải trong bài toán với giả định: để có một điểm truy cập toàn cục duy nhất thì chỉ có duy nhất một instance được tạo ra từ một class. Bài toán “một điểm truy cập” có thể được giải quyết bởi Facade, Wrapper… không nhất thiết phải là Singleton.
Runtime
– Không “thân thiện” với theading.
Design
– Coupling: Vì là global state nên các thành phần bị gắn chặt với nhau.
– Khó / không thể viết test.
– Viết dễ sai sót, để lại lỗ hổng (xem bài trước Singleton có thực sự dễ?).

Nên dùng như thế nào?
Như vậy, ta thấy rằng đa phần những thứ dở của design pattern này là ở tư tưởng global state. Vậy nên những ai yêu thích functional programming thì sẽ rất anti-pattern này. Cũng đúng thôi, GoF sinh ra cho OOP, không phải FP. Và thời đại của GoF (1994) cũng không quan tâm nhiều tới concurrency – bài toán trở thành rất cơ bản trong thời đại này. Bởi vậy, việc sử dụng Singleton có chút thay đổi. Có 3 điều cần chú ý:

1. Concurrency: Global state là điều tệ hại cho concurrency. Hãy giảm thiểu tối đa nếu có thể. Global state bẻ cong cách suy nghĩ về luồng và gây mệt mỏi cho việc debug trong concurrency. Nếu bạn muốn thiết kế hệ thống tối ưu hiệu năng và concurrency thì không sử dụng Singleton cũng là một ý hay.
2. Memory:
   – Lưu cái gì? Global state cũng là một ý hay vì khiến việc thiết kế và lập trình dễ dàng hơn, nó chỉ không hay khi bạn không cân nhắc tới nên lưu gì. Rất nhiều thứ có thể nhìn dưới góc độ một instance nếu chúng ta không có khả năng khái quát hoá. Logger là Singleton không? Hay có errorlog, accesslog? Database là single thì lưu cả database? Hay chỉ connection? Hay chỉ connectionString? Lưu ít nhất có thể.
   – Lưu khi nào? Nhiều người hay gắn Singleton với life cycle của cả ứng dụng, kèm theo việc lưu trữ nhiều, hoặc giữ strong reference dẫn đến GC không thể hoạt động; sớm muộn gì cũng gây ra memory leak. Khởi tạo muộn nhất có thể, giải phóng sớm nhất có thể.
3. Language: Cần lưu ý cách sử dụng trong từng ngôn ngữ, mỗi ngôn ngữ khác nhau sẽ có vấn đề khác nhau. Dù design pattern là mức thiết kế song đừng mang nguyên cách cài đặt từ ngôn ngữ này sang ngôn ngữ khác, hãy nhìn vào diagram và đặc trưng ngôn ngữ.

– Bài viết dựa trên môi trường làm việc là MacOs.
– Yêu cầu kĩ năng research cơ bản.
– Biết sơ qua các khái niệm: docker, kitematic, sqlserver, terminal (lol).

Cài đặt môi trường:
B1: Cài docker và sqlserver, 2 thằng này thì khá rõ để làm gì rồi ha. (hướng dẫn)
B2: Cài Kitematic, để quản lý các container (link)
B3: Chạy docker, chạy kitematic và start sql trong docker.
Lưu ý: Bỏ qua bước 2 và bước 3 nếu đã chạy sqlserver từ bước 1. Tuy nhiên khuyến khích cài đủ, chạy theo các step 1-2-3.

Tạo ứng dụng:
B1: Tạo ứng dụng mới ví dụ: asp-net-core-code-first
B1′: Thêm 2 thư viện Microsoft.EntityFrameworkCore.SqlServer và Microsoft.EntityFrameworkCore.Design
B2: Tạo class Person

public class Person
{
    public int Id { get; set; }
    public string Name { get; set; }
}

B3: Tạo class PersonContext

public class PersonContext : DbContext
{
   DbSet<Person> Persons { get; set; }

   protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
   {
     optionsBuilder.UseSqlServer("Server=localhost\\sql_server_demo,1433;User=sa;Password=reallyStrongPwd123;Database=PersonDb1");
   }
}

B4: Chạy migrate trong terminal dotnet ef migrations add initial
B5: Update database dotnet ef database update
Done!
Tham khảo: ciclosoftware

Một trong các đòi hỏi lớn của việc quản lý danh mục sản phẩm là phải thiết kế để đáp ứng các nhu cầu về hiệu năng và tích hợp với các hệ thống khác. Để đáp ứng các yêu cầu tốt, thì phải được thiết kế từ tổng thể ngay từ đầu. Có vậy mới tạo ra sự phát triển liền mạch, nhất quán giúp đảm bảo tính ổn định, cũng như tiến độ làm việc.

Continue reading

Đầu tiên chúng ta bắt đầu với bài toán quản lý sản phẩm với các nghiệp vụ phức tạp. Ví dụ hệ thống quản lý sản phẩm của các trang thương mại điện tử (Amazon, shoppe, tiki..).

Với bất kì sản phẩm phần mềm nào, chúng ta đều có chung mục đích thiết kế:

– DRY (Don’t Repeat Yourself), các nghiệp vụ được phân tách rõ ràng, cô đọng và tập trung cao.
– Có thể mở rộng, sửa đổi các thành phần độc lập.
– Linh hoạt trong việc phát triển.
– Dễ dàng test và bảo trì.

Các mục tiêu này sẽ ảnh hưởng tới cách thiết kế mô hình ứng dụng khác nhau. Chúng ta sẽ phân tích 3 mô hình thiết kế hay được sử dụng để tìm hiểu ưu, nhược điểm cũng như chọn cách thiết kế hệ thống phù hợp nhất.

Mô hình MVC

Mô hình MVC là mô hình phổ biến trong việc lựa chọn và xây dựng ứng dụng.
Đó là mô hình đơn giản, dễ tiếp cận và nhanh chóng đưa ra các tính năng.
Theo mô hình MVC thì phần quản lý sản phẩm sẽ theo mô hình như sau:

Với mô hình MVC như trên việc xử lý ở product model sẽ trở nên phức tạp. Lúc này product model sẽ là nơi:

– Định nghĩa các thuộc tính của product.
– Truy xuất database.
– Và thực thi các nghiệp vụ.

Thông thường mô hình MVC sẽ sử dụng pattern Active Record để mapping với database. Đây là cách làm đơn giản, nhưng có các hạn chế sau:

– Model product trở nên quá nặng khi chứa quá nhiều các logic từ định nghĩa thuộc tính, truy xuất dữ liệu, thực thi nghiệp vụ…
– Do không phân tách được các tầng nghiệp vụ và dữ liệu, nên khó thực hiện unit test các thành phần riêng biệt.
– Việc thay đổi logic truy xuất dữ liệu và logic nghiệp vụ khó khăn. Do các thành phần bị phụ thuộc vào nhau.
– Tính đóng gói của nghiệp vụ không đảm bảo. Các nghiệp vụ sẽ chỉ được cài đặt theo mô hình CRUD. Vì vậy càng về sau sự trùng lặp các logic càng cao.

Do các hạn chế đó nên đây không phải mô hình phù hợp với các ứng dụng logic phức tạp như ecommerce. Nó sẽ dẫn tới chi phí maintain về sau cao.

Mô hình ba lớp.

Hướng tiếp cận tiếp theo là phân tích và thiết kế theo phương pháp n-tier hay Domain Driven Design. Đặc trưng của mô hình này là:

– Phân tách tầng nghiệp vụ khỏi tầng ứng dụng và tầng truy xuất cơ sở dữ liệu. Tầng này gọi là Domain Layer. Tầng này là nơi chứa tất cả các logic nghiệp vụ.
– Trong tầng nghiệp vụ, tập trung vào design model sao cho model phản ánh đầy đủ nhất tính chất nhất quán của nghiệp vụ. Tầng này có thể chia thành 2 phần riêng biệt là Domain Model và Domain Service. Domain Service đóng vai trò cung cấp các nghiệp vụ ra bên ngoài (tới tầng Aplication) xoay quanh các domain model của hệ thống.
– Thiết kế tầng infrastructure chứa các logic về truy xuất dữ liệu, thao tác với database, messeage queue.

DDD Partern

Lợi ích:
Với việc tổ chức hệ thống này, các tầng ứng dụng, nghiệp vụ và data access sẽ chia tách riêng biệt, và chỉ tương tác thông qua interface. Các nghiệp vụ sẽ xoay quanh model product. Tầng data access sẽ truy xuất hoặc lưu trữ các object products.
Hạn chế:
Việc áp dụng mô hình 3 lớp xoay quanh model product cũng dẫn tới khó khăn là việc thiết kế model cho các nghiệp vụ đọc-dữ-liệu.
Đồng thời nó cũng ảnh hưởng tới tốc độ phát triển của hệ thống khi cài đặt các nghiệp vụ query đa dạng và phức tạp trong khi phuc vụ client. Việc này bị ảnh hưởng bởi cách thiết kế model và tầng Repository.

Mô hình CQRS

Mô hình CQRS (Command Query Responsibility Segregation) là sử mở rộng của mô hình trong ba lớp trong DDD. Đặc trưng quan trọng của CQRS là việc tách hai phần logic đọc và ghi dữ liệu ra hai phần riêng biệt:

– Phần ghi dữ liệu: được thực hiện qua việc send các command tới các handler thông qua command bus. Comand hanlder đóng vai trò tương tự domain service sẽ tương tác với các model để thực hiện các nghiệp vụ thay đổi dữ liệu.
– Phần đọc dữ liệu: được thiết kế riêng không lệ thuộc vào các model của phần ghi dữ liệu. Do đó có thể linh hoạt trong việc truy xuất database, cũng như sử dụng các data source khác nhau để tối ưu về tốc độ truy xuất.

Mô hình CQRS đã khắc phục các hạn chế đã nêu ở mục 2 bên trên. CQRS mang lại các lợi thế lớn:

– Cho phép phát triển và tối ưu phần đọc dữ liệu riêng biệt với phần ghi dữ liệu.
– Việc mô hình hoá các nghiệp vụ ghi dữ liệu dưới các command cho phép che đậy tốt các logic nghiệp vụ, giúp việc mở rộng dễ dàng hơn. Đồng thời các command đó có thể dễ dàng chuyển đổi giữa xử lý đồng bộ và bất đồng bộ thông qua lớp abstract là command bus mà không thay đổi mô hình. Giúp cung cấp một mô hình nhất quán, xuyên suốt trong bộ kiến trúc.

Tóm tắt về 3 mô hình (cả 3 mô hình trên đều có ưu/nhược điểm)

– Mô hình MVC đơn giản, nhưng hạn chế khi giải quyết nghiệp vụ phức tạp và testing, mở rộng
– Mô hình ba lớp phù hợp cho việc xử lý nghiệp vụ phức tạp, nhưng có nhiều hạn chế khi tối ưu phần đọc ra.
– Mô hình CQRS mở rộng từ mô hình ba lớp, giải quyết tốt việc chia tách đọc ghi, nhưng cũng đòi hỏi phải thiết kế phức tạp hơn.

Trên đây, chúng ta đã tìm hiểu qua về 3 mô hình khi thiết kế hệ thống. Và với các hệ thống lớn, cần đòi hỏi xử lý nghiệp vụ phức tạp, đồng thời đáp ứng hiệu năng, mô hình chúng ta nên chọn là CQRS. Mặc dù còn hạn chế về độ phức tạp khi triển khai, đòi hỏi team work cùng hiểu về hệ thống, tuy nhiên những giá trị mà nó mang lại nên được đánh đổi.

Phần tiếp theo chúng ta sẽ tìm hiểu tiếp về mô hình CQRS-ES.

Bài viết được tham khảo từ
tiki-engineering.
future-processing.

Ở bài trước mình đã giới thiệu với các bạn về UnitOfWork Design Pattern.

Nhắc lại vể lợi ích của 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

Bài toán:

Để hình dung rõ hơn, lần này chúng ta sẽ xem xét bài toán thực tế khi quản trị hệ thống muốn xóa một đơn hàng. Chúng ta cần xóa dữ liệu ở 2 bảng Orders và OrderDetails.

Theo cách làm thông thường, chúng ta sẽ xóa dữ liệu bảng OrderDetails trước, sau đó xóa dữ liệu bảng Orders. Với cách làm này rủi ro xảy ra nếu sau khi xóa dữ liệu bảng OrderDetails xong, một exception xảy ra (ví dụ kinh điển là mất mạng) lúc này dữ liệu bảng Orders chưa được xóa, dẫn tới việc không đảm bảo tính toàn vẹn dữ liệu và có thể gây lỗi hệ thống khi truy xuất đơn hàng.

Để giải quyết bài toán này. Chúng ta sử dụng pattern UnitOfWork, thực hiện việc xóa dữ liệu ở 2 bảng trong cùng 1 transaction. Bất kì ngoại lệ nào xảy ra, dữ liệu sẽ được rollback. Nếu thao tác xóa dữ liệu thành công, transaction sẽ được commit.

Đồ nghề:

• Database mẫu.

Xây dựng hệ thống

Cùng xem xét lại quan điểm:
Simplicity is the ultimate sophistication
Áp dụng thực tế vào bài toán khi làm việc với Database, để tránh việc code thừa ở khắp nơi khi gọi query dữ liệu. Trong ví dụ này chúng ta dùng thêm repository pattern để xử lý tầng kiến trúc làm việc với database.

Với tư tưởng như trên, chúng ta xây dựng lớp Repository chuyên xử lý các thao tác thông thường với database. Lớp OrderRepository xử lý các vấn đề đặc thù của Domain Order

Cấu trúc dự án tổng thể như sau:

Đầu tiên chúng ta xây dựng interface IRepository

public interface IRepository<TEntity> where TEntity : class
    {
        TEntity Get(int id);
        IEnumerable<TEntity> GetAll();
        IEnumerable<TEntity> Find(Expression<Func<TEntity, bool>> predicate);

        TEntity SingleOrDefault(Expression<Func<TEntity, bool>> predicate);

        void Add(TEntity entity);
        void AddRange(IEnumerable<TEntity> entities);

        void Remove(TEntity entity);
        void RemoveRange(IEnumerable<TEntity> entities);
    }

Và lớp Repository implement interface IRepository

public class Repository<TEntity> : IRepository<TEntity> where TEntity : class
    {
        protected readonly DbContext Context;
        protected readonly DbSet<TEntity> DbSetEntity;

        public Repository(DbContext context)
        {
            Context = context;
            DbSetEntity = Context.Set<TEntity>();
        }

        public void Add(TEntity entity)
        {
            DbSetEntity.Add(entity);
        }

        public void AddRange(IEnumerable<TEntity> entities)
        {
            DbSetEntity.AddRange(entities);
        }

        public IEnumerable<TEntity> Find(Expression<Func<TEntity, bool>> predicate)
        {
            return DbSetEntity.Where(predicate);
        }

        public TEntity Get(int id)
        {
            return DbSetEntity.Find(id);
        }

        public IEnumerable<TEntity> GetAll()
        {
            return DbSetEntity.ToList();
        }

        public void Remove(TEntity entity)
        {
            DbSetEntity.Remove(entity);
        }

        public void RemoveRange(IEnumerable<TEntity> entities)
        {
            DbSetEntity.RemoveRange(entities);
        }

        public TEntity SingleOrDefault(Expression<Func<TEntity, bool>> predicate)
        {
            return DbSetEntity.SingleOrDefault(predicate);
        }
    }

Interface IOrderRepository kế thừa từ IRepository

public interface IOrderRepository : IRepository<Orders>
{
    IEnumerable<Orders> GetTopOrders(int count);
    IEnumerable<Orders> GetOrdersWithCustomers(int pageIndex, int pageSize, string customerId);
}

Lớp OrderRepository kế thừa từ IOrderRepository và Repository

public class OrderRepository : Repository<Orders>, IOrderRepository
{

    public OrderRepository(NorthwindContext context) : base(context)
    {
    }

    public IEnumerable<Orders> GetOrdersWithCustomers(int pageIndex, int pageSize, string customerId)
    {
        return NorthwindContext.Orders
            .Where(o => o.CustomerId == customerId)
            .OrderBy(c => c.OrderId)
            .Skip((pageIndex - 1) * pageSize)
            .Take(pageSize)
            .ToList();
    }

    public IEnumerable<Orders> GetTopOrders(int count)
    {
        return NorthwindContext.Orders.OrderByDescending(c => c.OrderId).Take(count).ToList();
    }

    public NorthwindContext NorthwindContext
    {
        get { return Context as NorthwindContext; }
    }
}

Tiếp theo chúng ta tạo interface IUnitOfWork

public interface IUnitOfWork : IDisposable
{
    IOrderRepository Orders { get; }
    ICustomerRepository Customers { get; }
    IOrderDetailRepository OrderDetails { get; }
    int Complete();
}

Và implement của nó là class UnitOfWork

public class UnitOfWork : IUnitOfWork
{
    private readonly NorthwindContext _context;

    public UnitOfWork(NorthwindContext context)
    {
        _context = context;
        Orders = new OrderRepository(_context);
        Customers = new CustomerRepository(_context);
        OrderDetails = new OrderDetailRepository(_context);
    }

    public IOrderRepository Orders { get; set; }

    public ICustomerRepository Customers { get; set; }

    public IOrderDetailRepository OrderDetails { get; set; }

    public int Complete()
    {
        return _context.SaveChanges();
    }

    public void Dispose()
    {
        _context.Dispose();
    }
}

Vậy là chúng ta đã implement xong mô hình của hệ thống, áp dụng 2 partern là Repository và UnitOfWork.

Tiếp theo chúng ta sẽ tới lớp Program và viết mã test hoạt động của hệ thống trong hàm Main

Class program sẽ trông như sau:

class Program
{
    static void Main(string[] args)
    {
        using (var unitOfWork = new UnitOfWork(new NorthwindContext()))
        {

            // Example1
            var customersByCity = unitOfWork.Customers.GetCustomerByCity("London");

            // Example2
            var customers = unitOfWork.Customers.GetAll();

            // Example3
            var order = unitOfWork.Orders.Get(10250);
            var orderDetails = unitOfWork.OrderDetails.GetByOrderId(order.OrderId);
            unitOfWork.OrderDetails.RemoveRange(orderDetails);
            unitOfWork.Orders.Remove(order);
            unitOfWork.Complete();

            Console.WriteLine("Done!");
        }
    }
}

Source code