Lập trình Đà Nẵng: tháng 7 2018

Thứ Ba, 31 tháng 7, 2018

Tạo Java web project mẫu theo mô hình MVC

Chúng ta đã tìm hiểu sơ qua về mô hình MVC (Model – View – Controller) trong bài viết trước. Mình cũng đã giới thiệu về MVC áp dụng vào Java web như thế nào rồi. Vậy bây giờ như những gì đã hứa, mình sẽ hướng dẫn các bạn cách tạo Java web project mẫu theo mô hình MVC có kèm theo ví dụ đơn giản để bạn thực hiện theo.

Khâu chuẩn bị

Khi tổ chức một sự kiện đặc biệt thì khâu chuẩn bị là phần không thể thiếu, sự kiện diễn ra thành công hay không nhờ vào khâu chuẩn bị chu đáo.

Để đảm bảo khâu thực hành bên dưới không bị gián đoạn, bạn nên đọc qua các bài viết sau:

Cài đặt môi trường, công trình lập trình web với Java
Cách tạo java web project trong eclipse

Bao nhiêu đó thôi bạn nhé

Cấu trúc Java web project theo mô hình MVC

Trước khi tạo project theo chuẩn mô hình MVC thì bạn cần nhớ lại một ít kiến thức về MVC đã nhá. Nó bao gồm: Model (chứa thông tin đối tượng), View (giao diện), Controller (nhiệm vụ điều hướng, giúp model và view giao tiếp được với nhau)

Cấu trúc package và thư mục trong project

Tạo các folder và package như hình trên bạn nhé

Trong cấu trúc trên:

Các package:

com.ngockhuong.webmvc.controller: Chứa các servlet class thực hiện nhận request từ người dùng và trả về view tương ứng (nhiệm vụ điều hướng).

com.ngockhuong.webmvc.dao: Chứa các class thực hiện nhiệm vụ tương tác với cơ sở dữ liệu.

com.ngockhuong.webmvc.model: Chứa các class định nghĩa cho đối tượng, các class này sẽ được ánh xạ đến các bảng trong cơ sở dữ liệu.

com.ngockhuong.webmvc.service: Chứa các class có nhiệm vụ thực hiện các business logic (xử lý nghiệp vụ).

com.ngockhuong.webmvc.util: Chứa các class được định nghĩa để dùng như là các thư viện.

Các folder:

view: Chứa các file jsp.

Với project này, mình sử dụng servlet hoàn toàn để làm controller chứ không dùng làm view như đã nói ở bài trước. View thì dùng các trang jsp mà thôi

Lời thú nhận ngọt ngào

Bạn biết không? Mỗi người khi nắm rõ về mô hình MVC rồi thì họ lại có một cách tổ chức project cho riêng mình. Miễn sao nó hợp lệ, đúng chuẩn mô hình MVC, đảm bảo người khác đọc vào code sẽ hiểu. (không hiểu cũng chả sao nếu dự án đó là của riêng mình

)

Mình đã code nhiều dự án, mỗi dự án lại thay đổi cấu trúc project một ít (hay xem các project mẫu của người ta nên bắt chước theo ý mà

). Mình cũng từng thực tập tại các công ty, cấu trúc project ở mỗi nơi không giống nhau hoàn toàn, có thể thay đổi tên package hay folder lại một tý. Nhưng! Chức năng, nhiệm vụ mà các package, folder hay class, file đảm nhiệm sẽ không thay đổi (cứ theo chuẩn chức năng mô hình MVC thôi nhé

Ví dụ thế này:

Folder “view” nằm trong WebContent người ta có thể bỏ đi, đồng nghĩa với việc chứa trực tiếp các file jsp trong WebContent.
Package “com.ngockhuong.webmvc.util” có thể đổi tên thành “com.ngockhuong.webmvc.common“. (util và common chỉ là 2 cái tên, đặt như thế nào cũng được miễn đều có ý nghĩa là các tiện ích, phần chung, bổ sung thêm).
Package “com.ngockhuong.webmvc.service” có thể đổi tên thành “com.ngockhuong.webmvc.bo“. (servicelà dịch vụ, chuyên chứa các class xử lý business logic, các đối tượng được tạo từ các class đó gọi là business object. Do vậy có thể viết tắt thành bo để đặt tên cho package).
Hoặc một trường hợp nữa, các package như dao, service (bo) lại được chứa trong package model. Các class nhận nhiệm vụ ánh xạ tới table trong database (hay gọi với tên Java Bean) được chứa trong model thì giờ lại chuyển vào trong package bean (package bean chứa vào package model luôn).

Bạn có thể xem cấu trúc bên dưới để hiểu rõ hơn (Mình cũng đã từng dùng cấu trúc này cho project).

Một cấu trúc khác cũng tuân thủ mô hình MVC

Ý kiến cá nhân

Tóm lại, theo ý kiến của mình, bạn không nên lệ thuộc vào một cấu trúc nào cả. Bạn phải nắm chắc mô hình MVC, hiểu được các thành phần của mô hình MVC sẽ được áp dụng như thế nào trong web nói chung và java nói riêng. Đến với mỗi project tại mỗi team, mỗi công ty, bạn sẽ được giao cho một cấu trúc riêng để cả team cùng làm theo. Do vậy, không nắm được bản chất của vấn đề thì không thể làm được đâu bạn nhé.

Còn bây giờ, bạn còn đang học thì có thể áp dụng cấu trúc trên cho project của mình, có thể không được rất nhiềungười sử dụng nhưng vẫn được nhiều người dùng đó.

Để không bị lan man, mình sẽ viết ví dụ tạo java web project mẫu theo mô hình MVC tại một bài viết khác. Link sẽ cập nhật bên dưới bạn nhé

Bạn muốn học lập trình hãy liên hệ ngay với Mỹ Vân để được nhận ưu đãi từ học viện nhé

Khóa học Lập trình Python

Khóa học lập trình Java

Khóa học lập trình PHP

Khóa học lập trình Asp net

Khóa học lập trình Angular

Khóa học lập trình Ios

Khóa học lập trình React

Tìm hiểu về ngôn ngữ Angular và những đối tượng nên học

Ngày hôm nay mình sẽ chia sẻ mọi người về khái niệm tổng quan về ngôn ngữ lập trình Angular dành cho những bạn mới tìm hiểu biết về ngôn ngữ này sử dụng vào mục đích gì.

Trước hết các bạn nên tìm hiểu Angularjs là gì
Angularjs là một bộ mã JavaScript sử dụng để xây dựng những dự án Single page application hoạt động dựa trên nên tảng HTML và theo quy tắc của Angularjs . Đây là 1 mã nguồn mở hoàn toàn miễn phí được rất nhiều lập trình viên yêu thích. Framework này được các lập trình viên ở nước ngoài ưu chuộng rất nhiều có lẽ ở Việt Nam thì nó lại không được ít mọi người biết đến.
Vậy các lập trình viên nào nên học AngularJS
Nhưng bạn trẻ muốn theo nghề lập trình web và những ai muốn theo nghề lập trình AngularJS để khiến cho những dự án của mình thì nên theo học AngularJS.
các kiến thức bạn cần có nếu muốn học AngularJS
Để học được AngularJS bạn cần phải có kiến thức cơ bản về JavaScript, biết xử lý những object, string… bởi vì bản chất của AngularJS là 1 dạng single page áp dụng API để lấy dữ liệu nên bạn cần biết đến những kỹ thuật DHTML, Ajax.
các đặc tính đặc trưng của AngularJS
– AngularJS là 1 framwork phát triển trên javaScipt để tạo ra các ứng dụng
– AngularJS có thể phát triển frontend thông qua API data, sử dụng mô hình MVC rất tốt
– AngularJS tự động thích nghi với những trình duyệt nên những nhà lập trình viên không cần lo lắng vấn đề này
– AngularJS là ngôn ngữ lập trình miễn phí
> Ngoài lập trình AngularJS bạn có thể tìm hiểu về khóa học tester
những tình năng cốt lõi của AngularJS
– Data-binding: Tự động đồng bộ dữ liệu giữa model và view
– Scope: (Phạm vi) Đây là những đối tượng kết nối giữa Controller và View
– Controller: Đây là các hàm javascript xử lý kết hợp với bộ điều khiển Scope
– Service: Như tôi đề cập ở trên, AngularJS áp dụng các API được xây dựng từ những web service (PHP, ASP) để thao tác với DB.
– Filters: Bộ lọc lọc ra các thành phẩn của 1 mảng và trả về mảng mới
– Directives: đánh dấu vào các yếu tố của DOM, nghĩa là sẽ tạo ra những thẻ HTML tùy chỉnh
– Templates: hiển thị thông tin từ controller, đây là 1 thành phần của views
– Routing: chuyển đổi giữa những action trong controller
– MVC: Chia thành những phần riêng biệt như Model, View, Controller. Đây là một mô hình khá hay có lẽ trong Angular thì nó được chế biến lại một chút gần giốn đối với MVVM (Model View View Model)
– Deep Linking: Liên kết sâu, cho phép bạn mã hóa trạng thái của ứng dụng trong các URL để nó có thể đánh dấu được đối với công cụ tìm kiếm.
– Dependency Injection: Angular giúp những nhà phát triển tạo ứng dụng dễ dàng hơn để phát triển, hiểu và thử nghiệm dễ dàng.
Ưu và nhược điểm của AngularJS
– Ưu điểm: Cho phép tạo ra những ứng dụng đơn giản với code sạch, áp dụng data bind giống .Net, tình năng liên kết HTML giúp người dùng cảm thấy dễ áp dụng, có thể chạy trên nhiều trình duyệt và di dộng thông minh
– Nhược điểm: Không an toàn do sử dụng JavaScript nên về phía máy chủ phải đều đặn xác nhận quyền để hệ thống chạt trơn tru. Nếu các bạn sử dụng vô hiệu hóa Javascipt thì nó sẽ không áp dụng được.

Bạn muốn học lập trình hãy liên hệ ngay với Mỹ Vân để được nhận ưu đãi từ học viện nhé

Khóa học Lập trình Python

Khóa học lập trình Java

Khóa học lập trình PHP

Khóa học lập trình Asp net

Khóa học lập trình Angular

Khóa học lập trình Ios

Khóa học lập trình React

SOLID LÀ GÌ – ÁP DỤNG CÁC NGUYÊN LÝ SOLID ĐỂ TRỞ THÀNH LẬP TRÌNH VIÊN CODE “CỨNG”

Trong quá trình học, hầu như các bạn sinh viên đều được học một số khái niệm OOP cơ bản như sau:

Abstraction (Tính trừu tượng)
Encapsulation (Tính bao đóng)
Inheritance (Tính kế thừa)
Polymophirsm (Tính đa hình)

Những khái niệm này đã được dạy khá rõ ràng, và hầu như những buổi phỏng vấn nào cũng có những câu hỏi liên quan đến khái niệm này. Vì 4 khái niệm này khá cơ bản, bạn nào chưa vũng có thể google để tìm hiểu thêm.

Những nguyên lý mình giới thiệu hôm nay là những nguyên lý thiết kế trong OOP. Đây là những nguyên lý được đúc kết bởi máu xương vô số developer, rút ra từ hàng ngàn dự án thành công và thất bại. Một project áp dụng những nguyên lý này sẽ có code dễ đọc, dễ test, rõ ràng hơn. Và việc quan trọng nhất là việc maintainace code sẽ dễ hơn rất nhiều (Ai có kinh nghiệm trong ngành IT đều biết thời gian code chỉ chiếm 20-40%, còn lại là thời gian để maintainance: thêm bớt chức năng và sửa lỗi). Nắm vững những nguyên lý này, đồng thời áp dụng chúng trong việc thiết kế + viết code sẽ giúp bạn tiến thêm 1 bước trên con đường thành senior nhé (1 ông senior bên FPT Software từng bảo mình thế).

Ok, 10 phút quảng cáo đã qua, bây giờ đến phần giới thiệu. SOLID tức là “cứng”, áp dụng nhiều thì bạn sẽ code “cứng”. Đùa thôi, nó là tập hợp 5 nguyên tắc sau đây:

Single responsibility principle
Open/closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle

Trong nội dung bài viết này, mình chỉ giới thiệu tổng quát để các bạn có cái nhìn tổng quan về các nguyên lý này.

1. Single responsibility principle

Nguyên lý đầu tiên, tương ứng với chữ S trong SOLID. Nội dung nguyên lý:

Một class chỉ nên giữ 1 trách nhiệm duy nhất 
(Chỉ có thể sửa đổi class với 1 lý do duy nhất)

Để hiểu nguyên lý này, ta hãy lấy ví dụ với 1 class vi phạm nguyên lý. Ta có 1 class như sau

public class ReportManager()

{

   public void ReadDataFromDB();

   public void ProcessData();

   public void PrintReport();

}

Class này giữ tới 3 trách nhiệm: Đọc dữ liệu từ DB, xử lý dữ liệu, in kết quả. Do đó, chỉ cần ta thay đổi DB, thay đổi cách xuất kết quả, … ta sẽ phải sửa đổi class này. Càng về sau class sẽ càng phình to ra. Theo đúng nguyên lý, ta phải tách class này ra làm 3 class riêng. Tuy số lượng class nhiều hơn những việc sửa chữa sẽ đơn giản hơn, class ngắn hơn nên cũng ít bug hơn.

2. Open/closed principle

Nguyên lý thứ hai, tương ứng với chữ O trong SOLID. Nội dung nguyên lý:

Có thể thoải mái mở rộng 1 class, nhưng không được sửa đổi bên trong class đó 
(open for extension but closed for modification).

Theo nguyên lý này, mỗi khi ta muốn thêm chức năng,.. cho chương trình, chúng ta nên viết class mới mở rộng class cũ ( bằng cách kế thừa hoặc sở hữu class cũ) không nên sửa đổi class cũ.

3. Liskov Substitution Principle

Nguyên lý thứ ba, tương ứng với chữ L trong SOLID. Nội dung nguyên lý:

Trong một chương trình, các object của class con có thể thay thế class cha mà không làm thay đổi tính đúng đắn của chương trình

Hơi khó hiểu? Không sao, lúc mới đọc mình cũng vậy. Hãy tưởng tượng bạn có 1 class cha tên Vịt. Các class VịtBầu, VịtXiêm có thể kế thừa class này, chương trình chạy bình thường. Tuy nhiên nếu ta viết class VịtChạyPin, cần pin mới chạy được. Khi class này kế thừa class Vịt, vì không có pin không chạy được, sẽ gây lỗi. Đó là 1 trường hợp vi phạm nguyên lý này.

4. Interface Segregation Principle

Nguyên lý thứ tư, tương ứng với chữ I trong SOLID. Nội dung nguyên lý:

Thay vì dùng 1 interface lớn, ta nên tách thành nhiều interface nhỏ, với nhiều mục đích cụ thể

Nguyên lý này khá dễ hiểu. Hãy tưởng tượng chúng ta có 1 interface lớn, khoảng 100 methods. Việc implements sẽ khá cực khổ, ngoài ra còn có thể dư thừa vì 1 class không cần dùng hết 100 method. Khi tách interface ra thành nhiều interface nhỏ, gồm các method liên quan tới nhau, việc implement và quản lý sẽ dễ hơn.

5. Dependency inversion principle

Nguyên lý cuối cùng, tương ứng với chữ D trong SOLID. Nội dung nguyên lý:

1. Các module cấp cao không nên phụ thuộc vào các modules cấp thấp. 
   Cả 2 nên phụ thuộc vào abstraction.
2. Interface (abstraction) không nên phụ thuộc vào chi tiết, mà ngược lại.
( Các class giao tiếp với nhau thông qua interface, 
không phải thông qua implementation.)

Nguyên lý này khá lắt léo, mình sẽ lấy ví dụ thực tế. Chúng ta đều biết 2 loại đèn: đèn tròn và đèn huỳnh quang. Chúng cùng có đuôi tròn, do đó ta có thể thay thế đèn tròn bằng đèn huỳnh quanh cho nhau 1 cách dễ dàng.

Ở đây, interface chính là đuôi tròn, implementation là bóng đèn tròn và bóng đèn huỳnh quang. Ta có thể swap dễ dàng giữa 2 loại bóng vì ổ điện chỉ quan tâm tới interface (đuôi tròn), không quan tâm tới implementation.

Trong code cũng vậy, khi áp dụng Dependency Inverse, ta chỉ cần quan tâm tới interface. Để kết nối tới database, ta chỉ cần gọi hàm Get, Save … của Interface IDataAccess. Khi thay database, ta chỉ cần thay implementation của interface này.

nguồn: toidicodedao

Bạn muốn học lập trình hãy liên hệ ngay với Mỹ Vân để được nhận ưu đãi từ học viện nhé

Khóa học Lập trình Python

Khóa học lập trình Java

Khóa học lập trình PHP

Khóa học lập trình Asp net

Khóa học lập trình Angular

Khóa học lập trình Ios

Khóa học lập trình React