3 chuong 03 tủ tài liệu bách khoa

CHƯƠNG 3: MƠ HÌNH MVC Lịch sử MVC Khái niệm Model, View, Controller sử dụng từ năm 70 kỷ 20 phát triển từ đồ án Smalltalk XeroxPARC Tại nhìn nhận cách tổ chức ứng dụng GUI Một số nội dung chi tiết ban đầu mơ hình MVC gắn liền với khái niệm Smalltalk hình cơng cụ, khái niệm broader áp dụng vào ứng dụng Những khái niệm hoàn toàn phù hợp với ứng dụng web Tương tác với ứng dụng MVC dựa theo vòng tuần hồn hoạt động người dùng cập nhật view mà view trạng thái định (stateless) Mơ hình phù hợp với HTTP request response dùng ứng dụng web Xa nữa, MVC yêu cầu tách rời yếu tố bao gồm domain model controller logic tách riêng khỏi giao diện người dùng (UI) ứng dụng web Nghĩa HTML tách rời khỏi phần lại ứng dụng dẫn đến việc bảo trì sửa lỗi trở nên dễ dàng đơn giản Ruby on Rails dẫn đầu việc xây dựng lại mơ hình MVC ứng dụng xây dựng dựa mơ hình Một số MVC framework khác giới thiệu trình diễn ưu điểm mơ hình MVC, số có ASP.NET Tìm hiểu mơ hình MVC Ở khái niệm mức cao, mơ hình MVC có nghĩa ứng dụng MVC chia làm phần tách biệt, Models bao gồm thể liệu mà người dùng làm việc đó, view model đơn giản dùng để thể luồng liệu View controller domain models chứa liệu business hàm tính, chuyển đổi quy ước thao tác với liệu Views dùng để biểu diễn phần liệu model giao diện người dùng Controllers xử lý yêu cầu đến, thực tác vụ từ phía model lựa chọn view để biểu diễn liệu đến người dùng Model định nghĩa không gian không gian mà ứng dụng bạn hoạt động dựa theo Ví dụ, ứng dụng ngân hàng (Banking), model đại diện cho tất mà ứng dụng banking hỗ trợ account, sổ cái, giới hạn tiền gửi khách hàng … hoạt động dùng để thao tác liệu chuyển khoản rút tiền từ tài khoản Model chịu tách nhiệm đảm bảo tính tồn vẹn qn liệu Ví dụ: đảm bảo 66 giao dịch ghi vào sổ người dùng rút số tiền mà người có ngân hàng Các models định nghĩa dựa đại diện Model không đảm nhận công việc biểu diễn liệu giao diện người dùng, cơng việc Views Controllers View chứa yêu cầu logic để biểu diễn thuộc tính View cho người dùng, cơng việc mà View đảm nhận, khơng quan tâm trực tiếp đến model không trực tiếp giao tiếp với tầng Model Controller cầu nối Views Models Yêu cầu gửi từ phía client giải controler bao gồm lựa chọn view thích hợp để biểu diễn nội dung đến người dùng, cần, thực tác vụ tầng model Mỗi thành phần MVC định nghĩa chi tiết độc lập dựa vào yêu cầu khác Những tác vụ logic điều khiển liệu nằm Model Những tác vụ logic dùng để hiển thị liệu nằm tầng View phần code xử lý yêu cầu người dùng bao gồm thơng tin đầu vào có controller Với phân chia rõ ràng phần vậy, công tác bảo trì mở rộng ứng dụng trở nên dễ dàng xun suốt vòng đời nó, bất chấp độ lớn ứng dụng mà ứng dụng nới rộng Tìm hiểu Domain Model Phần quan trọng ứng dụng MVC Domain model Chúng ta tạo model cách xác định thực thể, tác vụ quy tắc tồn kinh doanh hoạt động mà ứng dụng hỗ trợ Sau tạo nên phần mềm để diễn tả domain đó, gọi domain model Nhằm đáp ứng mục tiêu ASP.NET MVC framework, domain model C# types (classes, struct ) biết đến domain types Những hoạt động domain biểu diễn methods xác định domain types Và quy tắc domain biểu diễn hàm logic bên method (Có thể tìm xem lại chương trước, cách áp dụng thuộc tính C#, thể (instance) domain type tạo để thể phần liệu, gọi domain object Domain model thường bảo toàn với vòng đời dài, có nhiều giải pháp cho tính chât domain model sở liệu quan hệ lựa chọn phổ biến ) Một cách ngắn gọn, domain model định nghĩa nhất, cao cấp business data quy trình bên ứng dụng Một domain model cố định nắm giữ định nghĩa cho trạng thái mà domain thể Chúng ta tiếp cận xử lý vấn đề nảy sinh Domain model trình bảo trì ứng dụng Nếu cần thiết phải điều chỉnh liệu Model thêm váo hoạt động hay quy tắc mới, domain model phần ứng dụng cần phải chỉnh sửa Mẹo: Một cách phổ biến để thực tách rời domain model khỏi phần lại ứng dụng ASP.NET MVC đặt model assembly C# tách biệt Bằng cách này, bạn tạo references cho domain model từ phần khác của ứng dụng đảm bảo khơng references miền khác Cách xây dựng hiệu project lớn Cách ASP.NET triển khai mơ hình MVC Trong MVC, controller lớp C# , thường kế thừa từ lớp System.Web.Mvc.Controller Mỗi public method lớp kế thừa từ Controller action method, nghĩa liên quan đến cấu hình URL thơng qua hệ thống định hướng ASP.NET (routing system) Khi yêu cầu đươc gửi đến URL tương ứng với action method đó, câu lệnh lớp Controller đươc thực thi để thực tác vụ domain model sau lựa chọn view để biểu diễn nội dung liệu phía Client ASP.NET MVC Framework sử dụng view engine, nghĩa cấu trúc đảm nhận việc phát sinh view nhằm tạo phản hồi Browser Những version trước MVC sử dụng chuẩn ASP.NET view engine, nghĩa xây dựng trang ASPX sử dụng streamlined version theo cú pháp Web Form MVC giới thiệu engine Razor, sử dụng cấu trúc cú pháp hoàn toàn khác (Sẽ miêu tả cụ thể chương 5) Razor cải tiến MVC không thay đổi MVC Mẹo: Visual studio cung cấp công cụ IntelliSense hỗ trợ cho Razor, giúp đơn giản hóa việc truyền nhận liệu đến view controller ASP.NET không áp dụng ràng buộc việc thực thi domain model.Người dùng tạo đối tượng C# bình thường sử dụng Database Bản đồ quan hệ đối tượng (ORM Framework) công cụ data hỗ trợ NET So sánh MVC với mơ hình khac MVC khơng phải kiến trúc xây dựng phần mềm Có nhiều kiến trúc khác vài số phổ biến Chúng ta học nhiều MVC tìm hiểu qua định nghĩa.Ở phần , bàn đến hướng tiếp cận khác xây dựng ứng dụng mặt đối nghịch chúng so với MVC Một số mơ hình có biến thể gần với MVC, số khác hồn tồn khác biệt MVC khơng hồn tồn mơ hình hồn hảo cho tất giải pháp phần mềm Trong số trường hợp, mơ hình xây dựng phần mềm khác hiệu MVC Chúng ta cần tìm hiểu cân nhắc kỹ lưỡng trước lựa chọn mơ hình Nội dung sách xoay quanh mơ hình MVC người phát triển phần mềm cần có tư mở cân nhắc để đưa định sáng suốt Hiểu mơ hình Smart UI Một mơ hình thiết kế phổ biến biết đến với tên gọi smart user interface (Smart UI) Hầu hết người lập trình tạo ứng dụng smart UI Nếu bạn sử dụng Web Forms ASP.NET Web Form bạn sử dụng mơ hình Để xây dựng ứng dụng Smart UI , người lập trình cấu trúc giao diện người dùng, thường công việc kéo thả thành phần controls lên giao diện rỗng ban đầu controls hồi đáp tương tác với người dùng xử lý kiện (events) (bấm nút, kéo thả chuột, tổ hợp phím…).Người lập trình thêm đoạn code để phản hồi lại kiện xử lý kiện (event handlers): đoạn code gọi kiện xác định xảy components Mơ hình tạo ứng dụng ngun khối hình Những đoạn code xử lý giao diện người dùng tác vụ business nằm tất mà không phân thành phần nhỏ Phần code xác định giá trị chấp nhận cho việc nhập liệu, truy vấn liệu sửa đổi thông tin tài khoản người dùng nằm phần nhỏ, liên kết với theo trật tự xếp theo yêu cầu kiện SmartUI ý tưởng nhằm tạo project đơn giản đạt hiệu thời gian ngắn (so sánh với mơ hình MVC (chương 7): MVC vốn đòi hỏi chuẩn bị kỹ lưỡng đầu tư từ ban đầu để đạt hiệu quả) Smart UI phù hợp với giao thức giao diện người dùng Công cụ thiết kế giao diện tốt dù WebForm hoạt động cách kỳ quặc khó đốn Nếu bạn tiếp xúc với khách hàng muốn thể nhanh ý tưởng yêu cầu giao diện luồng hoạt động giao diện, Smart UI công cụ nhanh đáp ứng việc tạo dựng thử nghiệm ý tưởng khác Một khuyết điểm Smart UI khó khăn cơng tác bảo trì mở rộng Sự trộn lẫn Model Business logic giao diện người dùng dẫn đến trùng lặp (duplication), mà mảng business chép lại nhiều lần để hỗ trợ thành phần thêm vào sau Tìm tất vị trí trùng lặp sửa chữa gặp nhiều khó khăn Việc thêm tính mà khơng ảnh hưởng đến tính có gần khơng thể Kiểm thử ứng dụng theo mơ hình Smart UI gặp nhiều khó khăn Cách giả lập giao tiếp người dùng, ngược lại ý tưởng kiểm thử khó khăn để thực công tác kiểm thử cách trọn vẹn Trong giới MVC, Smart UI thường xem phản mơ hình, cần phải tránh giá Những người tìm đến mơ hình MVC vốn dành nhiều thời gian họ để bảo trì phát triển ứng dụng Smart UI trước Mặc dù tồn nhiều luồng quan điểm, nhiên không nên đơn giản hóa vấn đề khơng nên loại bỏ phương án SmartUI hồn tồn Khơng phải tất thứ xấu mơ hình Smart UI, tồn nhiều mặt tích cực tiếp cận Ứng dụng Smart UI nhanh dễ dàng phát triển Những người tạo công cụ thiết kế component giao diện nỗ lực để đem đến trải nghiệm tốt Ngay người lập tình thiếu kinh nghiệm tạo ứng dụng với giao diện chuyên nghiệp đủ tính thời gian ngắn Điểm yếu lớn ứng dụng Smart UI khả bảo trì, khơng nên tốn cơng sức cho cơng tác bảo trì Nếu bạn xây dựng ứng dụng nhỏ đơn giản, Smart UI giải pháp hoàn hảo mà yếu tố phức tạp mô hình MVC khơng cần thiết Tìm hiểu kiến trúc Model-View Business Logic nguyên nhân dẫn đến khó khăn bảo trì SmartUI, gây dài dòng ứng dụng gây cản trở chỉnh sửa thêm tính Mơ hình Model-View đưa khắc phục vấn đề cách đẩy phần business logic thành phần domain model tách biệt Bằng cách này, liệu, process, quy tắc (Rules) kết nối với ứng dụng hình 3-3 Mơ hình model view cải thiện mơ hình ngun khối Smart UI lấy ví dụ vấn đề bảo trì Tuy nhiên có vấn đề nảy sinh: Vấn đề từ UI domain model tích hợp chặt chẽ với nhau, gây khó khăn để thực công tác unit testing Vấn đề thứ hai nảy sinh thực tế nhiều định nghĩa mơ hình Model thường chứa lượng lớn code truy suất liệu (không thiết thực tế thường gặp) điều nghĩa data model chứa business data, operation quy tắc Tìm hiểu kiến trúc lớp cổ điển (3 tier architecture) Để xác định vấn đề kiến trúc model-view, mơ hình ba lớp chia đoạn code cố định domain model đặt vào thành phần gọi lớp data access (data access layer) Hình 3-4 Kiến trúc ba lớp sử dụng phổ biến kiến trúc ứng dụng business Nó khơng có ràng buộc hoạt động UI phân chia yếu tố thành phần mà khơng biến trở nên q phức tạp Và quan tâm hơn, lớp DAL tạo để công tác unit testing thực cách tương đối dễ dàng Bạn nhận giống rõ ràng phần mềm theo kiến trúc ba lớp cổ điển kiến trúc.Sự khác biệt nằm việc lớp UI tách thành click-and-event GUI framework (như Windows Forms ASP.NET Web Forms) Nó trở nên bất khả thi để thực công việc unit test cách tự động Và UI phần kiến trúc lớp , trở nên phức tạp, nhiều phần code kiểm thử cách tỉ mỉ Trong trường hợp xấu nhất, mơ hình lớp thiếu tính chặt chẽ phân lớp UI, nghĩa nhìu ứng dụng theo trở nên giống ứng dụng theo mơ hình Smart UI(khơng có tách biệt thành phần) Điều gây hậu tệ , phần mềm kiểm thử, bảo trì trở nên vơ phức tạp Tìm hiểu biến thể MVC Chúng ta tìm hiểu mơ tả yếu tố ứng dụng MVC, đặc biệt vận hành ASP.NET MVC Một số định nghĩa mơ hình khác thêm bớt, vay mượn yếu tố mơ hình MVC để trở nên phù hợp với phạm vi nhu cầu dự an Trong phần , có nhìn sơ lược mơ hình dựa tảng MVC Nắm nội dung biến thể MVC không cần thiết làm việc ASP.NET MVC.Tuy nhiên nội dung vấn thêm vào để hoàn thiện kiến thức mơ hình phát triển phần mềm Tìm hiểu mơ hình Model View Presenter Model View Presenter biến thể MVC thiết kế để phù hợp với tảng GUI ổn định Windows Form ASP.NET Web Forms Đây nỗ lực nhằm đạt đến mô hình Smart UI giảm thiểu khuyết điểm đem lại Trong mơ hình MVP, lớp presenter đóng vai trò tương tự Controller MVC đồng thời đảm nhận mối quan hệ trực tiếp đến stateful view Trực tiếp điều khiển giá trị xuất phần giao diện dựa nhập liệu người dùng Có yếu tố triển khai mơ hình Passive view, view khơng chứa tác vụ logic _ nơi chứa UI controls điều khiển presenter Supervising controller (controller giám sát), view chịu trách nhiệm cho số thành phần logic trình bày ràng buộc liệu (data binding), cho phép tham chiếu từ nguồn liệu (data source) bên domain models Sự khác biệt hướng tiếp cận liên quan đến thơng minh lớp view Ngồi presenter tách từ GUI Framework, điều khiến thành phần presenter logic đơn giản phù hợp cho cơng việc unit testing Tìm hiểu mơ hình Model -View- View model Mơ hình Model view view model ( MVVM) biến thể gần MVC Nó xây dựng Microsoft sử dụng WPF (Windows Presentation Foundation) Trong mơ hình MVVM, Model view có vai trò MVC Sự khác biệt khái niệm MVVM nằm lớp view model Đây lớp trừu tượng thể giao diện người dùng Thường lớp C# cho thấy thành phần liệu biểu diễn UI tác vụ liệu gọi UI Khơng MVC controller, MVVM view model không tồn khái niệm view (hoặc định nghĩa UI khác) MVVM view sử dụng chực WPF binding để liên kết chiều với thuộc tính điều khiển view (item dropdown menu tác dụng bấm nút) với thuộc tính thể viewmodel Mẹo: MVC dùng khái niệm view model liên quan đến class model đơn giản dùng với mục đích truyền liệu từ controller vào view, đối nghịch với domain model vốn đại diện cho liệu, hoạt động quy tắc Loose Coupling (Độ phụ thuộc thấp) Một tính quan trọng mơ hình MVC cho phép chia nhỏ vấn đề cần quan tâm Chúng ta muốn phận ứng dụng phải độc lập có tính phụ thuộc lẫn khả xếp Ý tưởng cho giải pháp trên, thành phần khơng biết thành phần khác hoạt động với phần khác thông qua lớp lớp interface trừu tượng Đây xem độ phụ thuộc thấp (Loose Coupling) Nó khiến cho cơng đoạn kiểm thử chỉnh sưa trở nên dễ dàng Một ví dụ đơn giản giúp dễ hình dung, giả sử viết component tên MyEmailSender làm nhiệu vụ gửi email, thực mợi lớp interface để định nghĩa tất chức chung cần thiết để gửi email (tạm gọi IEmailSender) Tất component khác ứng dụng cần gửi email- giả sử chức trợ giúp reset lại password gọi hàm PasswordResetHelper gửi email cách liên hệ với hàm chức (method) lớp interface Khơng hè có phụ thuộc trực tiếp PasswordResetHelper MyEmailSender Hinh 3-5 Bằng giới thiệu IEmailSender, thấy khơng có phụ thuộc PasswordResetHelper MyEmailSender Chúng ta thay MyEmailSender nhà cung cấp e-mail khác xây dựng hàm chức giả nhằm mục đích kiểm thử mà khơng cần phải chỉnh sửa lại PasswordResetHelper (Chương 6) Sử dụng Dependency Injection Interface cho phép chia nhỏ components phải đối mặt với vấn đề: C# không hỗ trợ công cụ built-in dễ dàng tạo đối tượng thực thi interfaces, ngoại trừ tạo instance cụ thể component từ khóa Gỉa sử đoạn code Điều làm cản trở mục tiêu nhằm thay MyEmailSender mà khơng cần phải thay đổi PasswordResetHelper có nghĩa hoàn thành phần thao tác kết nối component riêng biệt PasswordResetHelper class cấu hình gửi mail thơng qua lớp interface IEmailSender, để tạo đối tượng thực thi lớp interface đó, phải tạo instance MyEmailSender Thực tệ, khiến vấn đề trở nên xấu PasswordResetHelper bị phụ thuộc vào MyEmailSender với lớp Interface IEmailSender Hình 3-6 Những cần cách để lấy đối tượng thực thi lớp interface mà không cần phải tạo đối tượng cách trực tiếp Giải pháp cho vấn đề gọi Denpendency Injection Hoặc biết đến với tên gọi Inversion of control (IoC) DI mơ hình thiết kế hồn thiện kết nối thành phần rời rạc Như miêu tả DI, tự hỏi lại cần đến thực khái niệm trung tâm quan trọng ảnh hưởng đến q trình phát triển ứng dụng MVC gây nhiều nhầm lẫn (confusion) Phá bỏ khai báo Dependencies Có phần mơ hình DI Thứ bỏ Dependency class cụ thể component Trong trường hợp PasswordResetHelper Chúng ta thực cách tạo class cấu trúc cho phép trình thực thi interface Hàm cấu trúc cho lớp PasswordResetHelper viết để khai báo phụ thuộc vào lớp interface IEmailSender, nghĩa khơng thể tạo sử dụng chừng nhận đối tượng thực thi lớp interface IEmailSender Bằng cách khai báo lệ thuộc, lớp PasswordResetHelper khơng chứa bất nội dung từ MyEmailSender Nó phụ thuộc vào lớp interface IEmailSender Một cách ngắn gọn, lớp PasswordResetHelper không cần biết quan tâm lớp interface IEmailSender vận hành Injecting Dependencies Phần thứ hai mơ hình DI chuyển đổi phụ thuộc khai báo từ lớp PasswordResetHelper tạo instance nó,do có khái niệm truyền lệ thuộc (Depencency Injection) Tất điều có nghĩa cần định sử dụng lớp để thực thi interface IEmailHelper tạo đối tượng từ lớp vào truyền đối tượng đối số vào hàm cấu trúc PasswordResetHelper Lưu ý hàm PasswordResetHelper khai báo tính lệ thuộc hàm cấu trúc Cơng việc gọi constructor injection Chúng ta khai báo tính lệ thuộc để chuyển đổi thơng qua thuộc tính public, định nghĩa setter injection Tính lệ thuộc chuyển đổi PasswordResetHelper mơi trường runtime Cũng cần phải nói, instance số class thực thi interface IEmailSender tạo truyền vào hàm cấu trúc lớp PasswordResetHelper q trình khởi tạo instance Khơng có qng thời gian biên dịch tính lệ thuộc lớp PasswordResetHelper lớp thực thi lớp interface mà phụ thuộc vào.Bởi lệ thuộc giải q trình runtime Chúng ta định tiến trình lớp interface sử dụng chạy ứng dụng Chúng ta chọn nhừng nhà cung cấp dịch vụ email khác chuyển đổi số tiến trình giả nhằm mục đích kiểm thử Dependency Injection cho phép đạt mối quan hệ mà nhắm đến hình 3-5 Sử dụng Dependency Injection Container Sử dụng vùng chứa (container) cho dependency injection Chúng ta giải vấn đề tính lệ thuộc nhanh chóng thực tác vụ interface mà không cần lệ thuộc nơi khác ứng dụng Như nêu, đoạn câu lệnh nằm ứng dụng : Câu trả lời để sử dụng vùng chứa dependency injection (còn dc gọi vùng chứa IoC) Đây components hoạt động người đường cho lớp PasswordResetHellper khai báo lớp để phân giải lệ thuộc nó, trường hợp IEmailSender Chung ta đăng ký nhóm kiểu interface abstract mà ứng dụng sử dụng với vùng chứa DI xác định lớp tác vụ nên sử dụng để thỏa mãn lệ thuộc Vì đăng ký interface IEmailSender với vùng chứa instance MyEmailSender nên khởi tạo tiến trình IEmailSender yêu cầu Khi muốn đối tượng PasswrodResetHelper ứng dụng mình, yêu cầu vùng chứa DI để tạo đối tượng Nó hiểu lớp PasswordResetHelper khai báo lệ thuộc vào lớp interface IEmailSender biết khai báo sử dụng lớp MyEmailSender lớp thực interface Vùng DI dựa vào ngn thơng tin đó, tạo đối tượng MyEmailSender sau sử dụng đối số để tạo đối tượng PasswordHelper để dùng ứng dụng Ghi nhớ: cần lưu ý điểm quan trọng khơng thể tự tạo đối tượng ứng dụng sử dụng keyword “new” Thay vào đó, vào chứa DI yêu cầu đối tượng cần Điều cần thời gian để làm quan học khái niện DI MVC Framework cung cấp số tính khiến công việc trở nên dơn giản Chúng ta khơng tự tạo DI container , có số mã nguồn mở miễn phí thực cơng việc đó.Một số cơng cụ Ninject (www.ninject.org) Chúng ta giới thiệu phần cài đặt sử dụng công cụ thông qua NuGet chương Mẹo: Microsoft tạo vùng chứa DI riêng, gọi Unity Để tìm hiểu thêm, vào unity.codeplex.com Vai trò DI container đơn giản không đáng kể, nhiên công cụ DI container Unity có số tính độc đáo Dependency chain resolution: Nếu yêu cầu conponent có phụ thuộc (tham số hàm cấu trúc), vùng chứa sẽ thỏa mãn phụ thuộc Vì thế, hàm cấu trúc cho lớp MyEmailSender đòi hỏi tiến trình bên phía lớp interface INetworkTransport, DI containner nhanh chóng thực tiến trình bên phía interface đó, chuyển đến hàm cấu trúc MyEmailSender trả kết tác vụ thực IEmailSender Object lifecycle management: Nếu yêu cầu component nhừng lần, liệu có nên lấy instance lần hay tạo instance mới? Một công cụ DI container tốt cho phép cấu hình vòng đời component, cho phép lựa chọn nhiều lựa chọn xác định trước bao gồm singleton (sử dụng instance cho lần gọi), transient(tạo instance lần thực hiện), instance-per thread, instance-per HTTP request, instance-from-a-pool nhiều lựa chọn khác Configuration of constructor parameter values: Nếu hàm cấu trúc cho tác vụ bên lớp interface INetworkTransport yêu cầu đạn mã string gọi serverName , lấy ví dụ, nên phép lấy giá trị cho từ phần cấu hình DI container Đây ước cấu hình hệ thống đơn giản loại bỏ việc truyền đoạn code connection strings, server addresses … Tự xây dựng DI container cách tuyệt vời để nắm cách C# NET xử lý kiểu ánh xạ Tuy nhiên không nên đặt phần code vào ứng dụng thực tế việc xây dựng DI container độ tin cậy cao, mạnh mẽ hiệu tốt khó khăn nên sử dụng gói sẵn có cho cơng việc Ngồi Ninject đề cập, có nhiều lựa chọn khác tùy thuộc vào sở thích phát triển người dùng Làm quen với kiểm thử tự động ASP.NET MVC Framework thiết kế giúp công việc cài đặt kiểm thử tự động đơn giản sử dụng công nghệ phát triển test-driven (TDD), đề cập đến phần sau chương ASP.NET cung cấp ý tưởng tảng dành cho việc kiểm thử tự động Visual Studio có số tính kiểm thử mạnh mẽ Giữa hai phần đó, họ thực kiểm thử thiết kế chạy thử đơn giản dễ dàng Trong định nghĩa rộng hơn, nhà phát triển ứng dụng web ngày tập trung vào hai loại kiểm thử tự động Loại Unit testing, cách xác định xác nhận hành động lớp độc lập (hoặc đơn vị code) cách chuyên biệt so với phần lại ứng dụng Loại thứ hai intergration testing (kiểm thử tích hợp) cách xác định xác nhận hành vi nhiều component làm việc nhau, mức ứng bao hàm toàn ứng dụng web Cả hai loại kiểm thử có giá trị ứng dụng web Unit tests tạo đơn giản chạy dễ dàng, hoạt động vô xác bạn cần kiểm định thuật tốn, business logic sở hạ tầng phía back-end Gía trị intergration testing có mơ hình hóa cách user tương tác vơi giao lớp UI bao hàm tồn tích hợp cơng nghệ ứng dụng bạn sử dụng, bao gồm web server database Kiểm thử tích hợp có xu hướng dễ dàng tìm bug vốn chưa xuất tính cũ, loại gọi regression testing(kiểm thử truy hồi) Tìm hiểu Unit testing Trong môi trường NET, tạo test project tách riêng Visual Studio nắm giữ thành phần phần kiểm thử (test fixtures) Porject tạo chọn add unit test tạo cách tự động sử dụng template project MVC Thành phần kiểm thử lớp C# định nghĩa test methods: method cho tính bạn mún xác nhận Một test project bao gồm nhiều lớp kiểm thử GETTING UNIT TEST FEVER Khả vận hành unit testing lợi nàm việc với MVC Framework khơng dành cho tất người Nếu bạn chưa phải làm công việc unit testing trước đây, lời khuyên cho bạn nên thử làm lần xem cách làm việc Một số thường thích sử dụng unit testing cho project họ không hẳn project nên không quán bạn mong đợi Chúng ta tập trung vào việc viết unit test cho tính hàm khó có khả nguồn gốc bug triển khai Trong trường hợp , unit testing giúp kiến trúc lại suy nghĩ cách thực điều cần Chỉ cần nghĩ việc kiểm thử giúp phát vấn đề tìm ẩn Trước bắt đầu với bug lỗi thực tế Cần ý unit testing công cụ, không bắt buộc cần phải ứng dụng lúc Nếu bạn nghĩa unit testing khơng giúp ích có cơng nghệ tốt phù hợp với nhu cầu thân bạn khơng cần phải thực công việc này.(Dù thực tế cách làm tốt tự kiểm thử, bạn để user người tìm bug bạn trở thành người phát triển xấu mắt người dùng Chúng ta không thiết phải thực unit test nên thực hành số ví dụ) Ghi chú: Chúng ta học cách tạo test project dùng làm unit testing chương Mục đích chương nhằm giới thiệu khái niệm unit testing cho người đọc ý tưởng thành phần kiểm thử (text fixture) dùng Để bắt đầu, tạo class ứng dụng tưởng tượng danh sách 3-1 Lớp gọi AdminController định nghĩa method ChangeLoginName cho phép người dùng thay đổi password họ Mẹo: Lớp tạo project Visual Studio có tên TestingDemo Người đọc không thiết phải tạo lại ví dụ để theo dõi Ví dụ tìm thấy trang Apress.com Controller dựa vào số lớp model interface list 3-2 Đây khơng phải project thực tế, ví dụ sách đơn giản hóa để miêu tả q trình kiểm thử dễ dàng Khơng khuyến khích người đọc tạo thêm lớp user có thành phần kiểu string Lớp user đại diện cho user ứng dụng user khởi tạo, quản lý lưu trữ kho chứa, tính định nghĩa lớp interface IUserRepository có tính hoàn chỉnh nằm tách rời lớp interface nằm lớp DefaultUserRepository Mục địch phần viết unit test cho tính cung cấp method ChangeLoginName định nghĩa AdminController.(miêu tả listing 3-3) Thành phần kiểm thử đoạn code method CanChangeLoginName Để ý method đặt thuộc tính TestMethod lớp thuộc sở hữu lớp AdminControllerTest (được đặt cho thuộc tính TestClass) Đây cách Visual Studio tìm thành phần kiểm thử Method CanChangeLoginName dựa mơ hình AAA(arrange/act/assert) Arrange (sắp xếp)liên quan đến việc thiết lập điều kiện cho kiểm thử, act việc thực vài test assert (xác nhận) xác nhận xác kết nhận kết cần đạt Thống kiến trúc method unit test khiến chúng dễ đọc Đôi cảm nhận project trở nên tốt có đến hàng trăm unit test Thành phần kiểm thử làm giả tác vụ lớp interface IUserRepository để giả lập tình cho trước Trong trường hợp này, có thành viên (Bob) kho chứa Nó khởi tạo kho chứa giả User giả phần Arrange q trình kiểm thử Tiếp theo đó, method AdminController.ChangeLoginName gọi trình kiểm thử Đây phần Act Cuối kiếm trả kết sửa dụng lời gọi Assert Assert method cung cấp Visual Studio cho phép người dùng kiểm tra kết đầu Chúng ta chạy test Visual Studio test meno nhận kết phản hồi thực trình kiểm thử hình 3-7 Nếu kiểm thử chạy mà không xảy exception chưa đươc xử lý tất câu lệnh Assert hoạt động mà không phát sinh lỗi, cửa sổ Test Explorer màu xanh, ngược lại màu đỏ kèm theo nội dung lỗi phát sinh Lưu ý: ý cách mơ hình DI giúp ích q trình thực unit testing Chúng ta tạo tác vụ giả kho chứa ánh xạ qua lớp controller để tạo trường hợp cụ thể Thoạt nhìn cần nhiều nỗ lực thực kiểm thử method đơn giản, nhiên kiểm thử tính phức tạp hơn, lại khơng đòi hỏi thêm q nhiều dòng code.Nếu bạn cảm thấy muốn bỏ qua kiểm thử nhỏ trên, nhớ test fixtures (thành phần test) cho phép tìm bug tính phức tạp hơn.Chúng ta cải thiện kiểm thử vừa cách loại bỏ lớp giả tạo trình kiểm thử (FakeMemberRepository) cách sử dụng công cụ (sẽ đề cập chương 6) Sử dụng TDD Red-Green-Refactor Workflow Với TDD (Test-driven developement), sử dụng unit test để thiết kế đoạn code Đây khái niệm lạ bạn quen việc testing sau hồn tất q trình coding, nhiên hướng tiếp cận lại hay Nội dung khái niệm xây dụng workflow gọi red-green-refactor Nó hoạt động sau  Xác định bạn cần để thêm tính method vào ứng dụng  Viết kiểm thử xác nhận hành vi tính tạo  Chạy kiểm thử nhận kết đèn đỏ (red light)  Viết phần code thực tính  Chạy lại test chỉnh sửa phần code nhận đèn xanh (greenligth)  Chỉnh sửa lại đoạn code bạn thấy cần thiết (thiết kế lại câu lệnh,đổi tên biến …)  Chạy lại test để xác nhận thay đổi không ảnh hưởng đến hoạt động tính bạn vừa thêm vào Hướng làm việc lặp lại thêm tính TDD hướng phát cổ điển Chúng ta bắt đầu cách viết test cho tính hoạt động hồn chỉnh, chắn test khơng đạt u cầu Sau thực tính đó, xây dựng thành phần tính để vượt qua nhiều test Vòng tròn chất TDD Nó nhiều ý kiến tích cực nên áp dụng phong cách lập trình, khiến người phái triển xác định đươc thay đổi cải tiến cho ứng dụng trước bắt đầu giai đoạn coding Chúng ta ln có đích đến rõ ràng việc kiểm tra liệu đến đích đến chưa Nếu bạn dự đính ứng dụng unit test ứng dụng mình, bạn chắn yếu tố thêm vào không thay đổi hoạt động phần khác TDD lạ làm quen với nó, nhiên hướng tiếp cận mạnh mẽ Khi viết test trước đảm bảo hình dung tính hoạt động cách hoàn chỉnh giúp chọn hướng trình coding Một điểm trừ TDD đòi hỏi tính kỷ luật Khi hạn chót đến gần, đơi muốn bỏ phần TDD vào phần coding Trong project thực tế, có nhiều người lút bỏ phần kiểm thử nhằm khiến cho phần code tốt đẹp chất thực Vì lí đó, TDD nên sử dụng môi trường làm việc nghiêm túc, cần kỷ luật kỹ cao đội ngũ phát triển giúp việc thực tiến hành áp lực thời gian Tìm hiểu kiểm thử tích hợp (Intergration Testing) Trong ứng dụng web, cách tiếp cận phổ biến kiểm thử tích hợp UI automation Nghĩa giả lập tự động hóa tạo thao tác người dùng (nhất nút, chọn follow xác nhận mẫu đơn …) trình duyệt web để thực hành ứng dụng môi trường công nghệ Hai công cụ mã nguồn mở phục phụ tự động hóa hỗ trợ phát triển NET bao gồm:  Selenium RC (http://seleniumhq.org/), bao gồm ứng dụng java server tự động gửi câu lệnh đến IE, Firefox, Safari Opera, thêm người dùng cho NET, Python, Ruby nhiều framework khác, bạn chọn ngơn ngữ theo sở thích Selenimum cơng cụ mạnh chuyên dụng, điểm trừ hoạt động Java server  WatiN (http://watin.org), thư viện NET gửi yêu cầu tự động đến IE Firefox API công cụ không mạnh Selenium giải hầu hết ngữ cảnh dễ dàng cài đặt Bạn cần file DLL Kiểm thử tích hợp ý tưởng bổ sung cho unit testing Mặc dù unit testing phù hợp để kiểm thử hành động components riêng biệt server Kiểm thử tích hợp cho phép bạn tạo kiểm thử tập trung vào phía client, xây dựng hành động user Kết đạt phát vấn đề trình tương tác component, ý nghĩa khái niệm kiểm thử tích hợp.Vì kiểm thử tích hợp thực web browser , kiểm tra câu lệnh Javascript có chạy u cầu, đơi việc gặp nhìu khó khăn unit testing Có số khuyết điểm kiểm thử tích hợp cần nhiều thời gian hơn, cần nhiều thời gian để xây dựng test thời gian để thực chúng Kiểm thử tích hợp khơng chăn Lấy ví dụ Nếu bạn thay đổi thuộc tính id elements kiểm tra test, test thường không đạt yêu cầu Kết đạt bỏ nhiều thời gian công sức hơn, kiểm thử tích hợp thường hồn thành cột mốc quan trọng trình phát triển kiểm tra phần code hồn thành tuần hay hồn thành tính lốn Kiểm thử tích hợp hiệu tương đương Unit testing phát lỗi mà unit testing khơng phát kiểm thử tích hợp trình nên đầu tư thời gian để cài đặt thực hiện.Chung ta nên thêm vào trình phát triển truy nhiên sách khơng đề cập đến kiểm thử tích hợp Nó nằm nội dung MVC framwork Mọi web app thực kiểm thử tích hợp thu kết nhiên khơng có tính MVC Framework hỗ trợ hoạt động Kiểm thử tích hợp phần tách biệt, thực kiểm thử tích hợp ứng dụng web mơ hình MVC Tổng hợp Trong chương học mơ hình kiến trúc MVC so sánh với mơ hình kiến trúc khác thấy nghe qua Chúng ta bàn ý nghĩa domain model giới thiệu dependency injection, tính cho phép tách components để phân chia rõ ràng thành phần ứng dụng Mô tả công việc kiểm thử unit testing mức độ bản, cách phân chia components dependency injection giúp công việc kiểm thử unit testing trở nên dễ dàng Trong chương bàn tính cần thiết C# sử dụng ứng dụng MVC Framework ... bao gồm thể liệu mà người dùng làm việc đó, view model đơn giản dùng để thể luồng liệu View controller domain models chứa liệu business hàm tính, chuyển đổi quy ước thao tác với liệu Views dùng... hạn tiền gửi khách hàng … hoạt động dùng để thao tác liệu chuyển khoản rút tiền từ tài khoản Model chịu tách nhiệm đảm bảo tính tồn vẹn qn liệu Ví dụ: đảm bảo 66 giao dịch ghi vào sổ người dùng... không phân thành phần nhỏ Phần code xác định giá trị chấp nhận cho việc nhập liệu, truy vấn liệu sửa đổi thông tin tài khoản người dùng nằm phần nhỏ, liên kết với theo trật tự xếp theo yêu cầu