Trước khi chúng ta tạo giao diện người dùng cho một chương trình, chúng ta cần biết chương trình đó dùng để làm gì. Hy vọng rằng chúng ta sẽ tạo một chương trình logic cho người dùng. Bên dưới những giao diện đẹp đẽ chúng ta xây dựng, có những thứ chúng ta cố gắng hoàn thiện những dữ liệu và thông tin muốn truyền đạt. Trước khi chúng ta bắt đầu thảo luận làm thế nào để tạo một giao diện người dùng hiệu quả, chúng ta cần xác định thông tin cốt lõi mà chúng ta đang làm việc.
Khi chúng ta thảo luận về kiến trúc phần mềm, các yếu tố cốt lõi của chương trình chúng ta là “Model”. Thuật ngữ này xuất phát từ các mẫu thiết kế kiến trúc từ rất lâu trước đây. “Model” được sử dụng hầu hết trong các mẫu thiết kế giao diện người dùng và cũng là thuật ngữ được sử dụng nhiều từ trước cùng với SmallTalk ở thập niên 70 khi Trygve Reenskaug lần đầu miêu tả mẫu thiết kế Model-View-Controler.
Khi nói về Model, chúng ta đang nói đến dữ liệu tên miền cụ thể và logic hay “phần ruột” của bản thân chương trình. Trong một thế giới lý tưởng, ít nhất là về mặt lý thuyết và kiến trúc, chương trình có thể làm việc mà không cần giao diện người dùng phải hiển thị tất cả, miễn là nó có các thông tin thích hợp được chuyển đến. Logic kinh doanh cốt lõi cũng không cần hoặc không muốn biết bất cứ điều gì về làm thế nào nó đang được sử dụng – điều này nằm ngoài phạm vi những gì nó quan tâm.
Logic kinh doanh của bạn chỉ nên biết về kinh doanh, không cần biết thêm điều gì khác. Đây chính là chìa khóa để thiết kế sản phẩm với khả năng bảo trì hệ thống dễ dàng. Điều này cũng rất hữu ích cho việc duy trì một chương trình theo thời gian. Việc giữ Model tách biệt làm cho ứng dụng dễ dàng được mở rộng sang lĩnh vực khác mà không cần sao chép mã hoặc phá vỡ kiến trúc đã xây dựng. Ví dụ, nếu logic kinh doanh của bạn hoàn toàn tách biệt, bạn có khả năng chuyển đổi mà không thay đổi các logic kinh doanh của bạn, từ việc sử dụng một máy tính để bàn, ứng dụng phía khách hàng sử dụng một dòng lệnh, kịch bản dựa trên các phiên bản của ứng dụng của bạn. Trong một số trường hợp, bạn có thể tạo cùng một logic và lưu trữ nó, truy cập từ xa thông qua một trang web.
Trong hầu hết các trường hợp, dễ hiểu nhất có thể xem Model như là dữ liệu. Nếu bạn đang tạo ứng dụng để chỉnh sửa thông tin khách hàng thì thông tin khách hàng (dữ liệu) ở đây chính là Model. Tuy nhiên, Model cũng có thể đóng gói các logic bên trong nó. Nếu bạn có một dịch vụ (service) cần được gọi đến như là một phần của logic kinh doanh khi dữ liệu được cập nhật, bản thân dịch vụ này có thể được xem như là một phần của Model. Khi thảo luận về những chức năng mà chương trình thực hiện, như nó “làm việc trên” cái này (dữ liệu) hay “thực hiện công việc này” (logic) thì nghĩa là bạn đang nói về Model. Tuy nhiên, nếu thảo luận về cách người dùng tương tác với chương trình như thế nào thì có nghĩa là bạn đang nói về những thứ bên ngoài của Model.
Tôi muốn đề cập vấn đề mà tôi thấy thường dễ gây nhầm lẫn nhất ở đây. Nếu bạn có một ứng dụng xử lý dữ liệu nhiều tầng thì tất cả các tầng xử lý dữ liệu và tầng logic là một phần của (hay dưới) Model. Với mục đích của chúng ta, chúng ta xử lý tầng dữ liệu và tầng logic như là một tầng bên trong Model. Ở đây, tầng logic hoạt động như một API công cộng (public) của Model và chúng ta sử dụng đó như Model. Tầng trình diễn (Presentation) được tách biệt với Model, nhưng những gì mà người dùng “làm việc trên” dữ liệu và tên miền logic cụ thể để thao tác dữ liệu sẽ là các phần của Model.
Cho series của chúng ta, chúng ta sẽ làm việc với một chương trình đơn giản là chương trình đọc nguồn RSS. Khi chúng tôi nói về các chương trình , tất cả ba phiên bản của chương trình chúng ta sẽ phát triển sử dụng cùng một Model. Phần API chung của Model chỉ có 2 lớp: Feed và FeedItem. Lớp Feed có một số thuộc tính (Title, Description,…) và một tập hợp các thể hiện của FeedItem. Lớp FeedItem chứa các thuộc tính cho các thông tin về mỗi mục trong mỗi Feed, bao gồm Title, Link đến mục gốc và Description của mục nguồn này. Lớp Feed cũng có thêm một số logic bên trong – một phương thức tĩnh cho phép tạo một Feed trên một Uri cho trước.
Điều quan trông nhất đối với lớp Feed và FeedItem này đó là chúng chỉ mô tả dữ liệu và cung cấp các phương tiện để tải dữ liệu. Các lớp này sẽ không mô tả bằng cách nào và như thế nào để chỉnh sửa hay hiển thị dữ liệu. Bởi vì Model chỉ cho thấy dữ liệu chứ không cho phép thao tác hay trình diễn trên dữ liệu đó bởi người dùng. Ở đây chúng ta có thể sử dụng cùng kết cấu (assembly) và không thay đổi trong tất cả 3 phiên bản ứng dụng.
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?