Bài dịch: How We Code: ORMs and Anemic Domain Models (Phần 1)

Source: http://fideloper.com/how-we-code

Rất nhiều cuốn sách quý về kiến trúc code được viết bởi những lập trình viên giàu kinh nghiệm với ngôn ngữ lập trình hướng đối tượng, như Smalltalk và Java. Các ngôn ngữ này phát triển mà không có phần lớn những công cụ hữu ích trong framework hiện nay. Trên thực tế, những tác giả và lập trình viên nói trên đã tạo ra hầu hết những “best pratices” mà chúng ta sử dụng hôm nay.

Những framework trong ngôn ngữ hiện đại đã được sinh ra từ những “best pratices” trên. Tuy nhiên, chúng thường phức tạp. Chúng cung cấp nhiều công cụ hữu dụng cho việc xây dựng ứng dụng, nhưng lại để cho lập trình viên tự hiểu cách triển khai chúng một cách có tổ chức. Chúng ta cần một thứ gì đó dễ dàng hơn. Thật may mắn, những người thuộc công ty 37 Signals đã làm điều này.

Rails đã mở ra một cuộc cách mạng trong việc phát triển web. Nó tập trung vào việc Phát Triển Ứng Dụng Nhanh Chóng [Rapid Application Development (RAD)] bằng việc giới thiệu phương pháp làm thế nào để xử lý những vấn đề cơ bản trong ứng dụng. Những phương pháp đó hạn chế chúng ta tự thực hiện cách làm riêng của mình, và cho phép chúng ta tập trung vào các chức năng.

1. Rails là một framework nổi tiếng của ngôn ngữ lập trình Ruby.

2. Một số những vấn đề cơ bản trong ứng dụng.
Authentication, Authorization, Caching, Validation, Localization, Session…

Nhìn thấy sự thành công của Rails, những framework khác (thuộc ngôn ngữ khác) cũng nhanh chóng chuyển sang cách làm này.

Tuy nhiên, sau khi sử dụng framework theo định hướng RAD, chúng ta đánh mất (hoặc sẵn sàng bỏ qua) rất nhiều bài học mà những người đi trước đã phải cặm cụi học.

Chúng ta code rất nhiều với những công cụ đó, vì chúng là những công cụ tuyệt vời. Tuy nhiên, những RAD framework có xu hướng trở thành những ứng dụng, thay vì là những công cụ đơn giản để triển khai ứng dụng. Ví dụ: chúng ta thường nói rằng "skinny controller, fat model" nhưng sau đó nhồi nhét những business logic vào trong lớp dịch vụ hoặc lớp bền vững (service layer or persistence layer) thay vì vào trong model.

1. "skinny controller, fat model" nghĩa là số dòng code ở controller nên ít nhất có thể, thay vào đó, những việc xử lý khác sẽ ở model.

2. Persistence layer hay Data Access layer là lớp chứa code để truy cập vào data từ database hoặc cache.

Trong nghiên cứu của tôi về kiến trúc code, tôi đã nhận thấy rằng có một điều đặc biệt, chúng ta viết business logic code ở đâu? Ở Active Record ORMs. Active Record ORMs mạnh, tiết kiệm thời gian, nhưng cũng là nguyên nhân gây ra xích mích trong ứng dụng.

Trong baì viết này, tôi sẽ đưa ra ví dụ về cách thực hiện một vài businesss logic trong một Active Record patterns thông thường, và tôi sẽ chỉ ra cách để những logic đó có thể được áp dụng khi sử dụng Data Mapper pattern. Trong cả 2 cách, chúng ta sẽ biết làm thế nào để di chuyển business logic vào business entities, như vậy sẽ tránh được việc xử lý nghiệp vụ kém hiệu quả. Chúng ta cũng sẽ được biết ưu điểm và nhược điểm của Active Record và Data Mapper, và chúng ảnh hưởng đến cách chúng ta viết code như thế nào.

Active Record: http://www.martinfowler.com/eaaCatalog/activeRecord.html

Data Mapper: http://martinfowler.com/eaaCatalog/dataMapper.html

(Còn tiếp.)