Sử dụng Application_Error trong global.asax của ASP.NET MVC để xử lí Exception

ASP.NET MVC hỗ trợ chúng ta rất nhiều cách để handle và xử lí Exception. Ví dụ như:

- Try...catch...trực tiếp trong các action method.

- Override method OnException trong controller.

- Sử dụng thuộc tính HandleError hoặc chúng ta có thể tự tạo thuộc tính để xử lí lỗi thông qua việc kế thừa  HandleErrorAttribute.

- Xử lí HTTP Errors trong file Web.config.

- Xử lí Application_Error trong global.asax.

Tùy vào nhu cầu của mình mà chúng ta có thể xử lí exception theo một hay nhiều cách khác nhau. Trong bài viết này, Kiên sẽ hướng dẫn các bạn xử lí exception trong file global.asax.

Nếu bạn không muốn phải xử lí lỗi trong từng controller hay từng method, hoặc giả sử chúng ta bỏ sót không xử lí exception ở một nơi nào đó, hoặc chúng ta thích quản lý tập trung các exception, thì việc xử lí exception bằng cách khai báo method Application_Error trong file global.asax này khá là hữu dụng.

Ưu điểm khác là bạn có thể bắt tất cả các lỗi, đồng thời có thể thực hiện nhiều yêu cầu trong cùng một nơi. Ví dụ như khi có lỗi xảy ra, bạn muốn ghi log lại, đồng thời gửi mail hoặc thông báo đến admin, sau đó có thể redirect đến trang thông báo lỗi...

Cách thực hiện chức năng này khá đơn giản.

Đầu tiên chúng ta vào file global.asax và bổ sung thêm vào đó method Application_Error bởi vì ASP.NET MVC mặc định sẽ không có method này.

   public class MvcApplication : System.Web.HttpApplication  
   {  
     protected void Application_Start()  
     {  
       AreaRegistration.RegisterAllAreas();  
       GlobalConfiguration.Configure(WebApiConfig.Register);  
       FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);  
       RouteConfig.RegisterRoutes(RouteTable.Routes);  
       BundleConfig.RegisterBundles(BundleTable.Bundles);  
     }  

     void Application_Error(object sender, EventArgs e)  
     {  
       //get the last error of server  
       var error = Server.GetLastError();  

       //get the http code of error: 400, 404, 500...  
       var code = (error is HttpException) ? (error as HttpException).GetHttpCode() : 500;  

       //write log  

       //send email  

       //clear response stream  
       Response.Clear();  

       //clear server's error  
       Server.ClearError();  

       //redirect to error page  
       Response.Redirect(string.Format("~/Error/Index/{0}", code));  
     }  
   }  

Hãy nhìn vào Application_Error để biết những gì mà chúng ta cần phải làm:

1. Đầu tiên chúng ta lấy được lỗi mới xảy ra thông qua method Server.GetLastError. Đây có thể là bất kì lỗi nào chứ không nhất thiết chỉ là lỗi HttpException.
2. Khi đã bắt được lỗi thì việc tiếp theo là chúng ta có thể xử lí tùy ý. Ở đây Kiên sẽ ghi log lại để tiện trong việc tracking và đồng thời gửi mail đến cho mình.
3. Tiếp theo là chúng ta phải clear response stream để đảm bảo là tất cả nội dung được viết trong response phải được xóa hết.
4. Sau đó là chúng ta tiếp tục clear tất cả lỗi hiện tại đi.
5. Và cuối cùng là chúng ta sẽ điều hướng sang một trang mới dùng để hiển thị thông điệp cho người dùng, đồng thời truyền đi HTTP code để hiển thị thông tin phù hợp.

Bước tiếp theo là ta tạo ErrorController với action method có một tham số như bên dưới, và sau đó hãy nhớ add view cho nó.

   public class ErrorController : Controller  
   {  
     // GET: Error  
     public ActionResult Index(int id)  
     {  
       Response.StatusCode = id;  
       ViewBag.StatusCode = id;  
       return View();  
     }  
   }  

Vậy xem như chúng ta cơ bản đã hoàn thành việc xử lí lỗi thông qua Application_Error trong file global.asax. Hãy để lại comment bên dưới nếu bạn muốn trao đổi thêm!

Share to be shared!

Partial Class trong C#

Partial Class là gì?

Partial Class trong .C# là một tính năng giúp chúng ta chia một class thành hai hay nhiều phần hay file khác nhau. Các phần hay file này chứa một phần tính năng của class đó, đó có thể là properties, methods...Tất cả những phần này, file này sẽ được tích hợp lại bên trong class khi chúng ta biên dịch (compile) chương trình.

Vậy khi nào chúng ta sử dụng Partial Class?

Partial Class sẽ rất hữu dụng khi chúng ta muốn:

- Cần bổ sung, cập nhật chức năng cho một class nhưng chúng ta không muốn hoặc không thể sửa đổi trực tiếp trong class này. Giả sử chúng ta có một class Convert bao gồm các method dùng chung trong hệ thống dùng để convert các kiểu dữ liệu. Sau một thời gian chúng ta muốn bổ sung thêm một vài method vào class Convert này mà không muốn phải tạo một class hoàn toàn mới thì Partial Class sẽ giải quyết vấn đề này cho chúng ta.

Ví dụ:

   /// <summary>  
   /// My first Convert class  
   /// </summary>  
   public static partial class MyConvert  
   {  
     public static int ToInt(string value)  
     {  
       return int.Parse(value);  
     }  
     //other methods  
   }  
   /// <summary>  
   /// My second Convert class  
   /// </summary>  
   public static partial class MyConvert  
   {  
     public static decimal ToDecimal(string value)  
     {  
       return decimal.Parse(value);  
     }  
   }  

Và kết quả sau khi compile: chúng ta có hai method bên trong class Convert dù được viết trong 2 class khác nhau.

- Chia để trị. Khi ta muốn chia class thành nhiều phần có mục đích rõ ràng: một phần dùng để kế thừa và thực thi các method của parent class hay interface, một phần khác thực thi các khai báo, method của riêng nó. Nó sẽ rất có ích nếu ta có một class lớn với hàng trăm, hàng ngàn dòng code hoặc ta có class mà nhiều người có thể thực thi cùng một lúc. Ví dụ điển hình là khi chúng ta design form trong C#, Visual Studio sẽ tách Form thành 2 file riêng biệt là "Form1.cs" xử lí nghiệp vụ, events...và "Form1.designer.cs" dùng để khai báo, thiết kế control.

Ví dụ: ta có một partial class Person dùng để khai báo các property và method của riêng nó, một partial class Person khác dùng để thực thi method Clone từ interface ICloneable.

 namespace chkien0911.PartialClass  
 {  
   public partial class Person  
   {  
     public string Name { get; set; }  
     public DateTime Birthday { get; set; }  
     public int GetAge()  
     {  
       return DateTime.Now.Year - Birthday.Year;  
     }  
   }  
   public partial class Person : ICloneable  
   {  
     /// <summary>  
     /// Implement interface's method  
     /// </summary>  
     /// <returns></returns>  
     public object Clone()  
     {  
       return this.MemberwiseClone() as Person;  
     }  
   }  
 }  

Kết quả sau khi compile:

- Khi chúng ta sử dụng tính năng tạo code tự động mà làm các bổ sung của chúng ta bị mất đi. Lấy ví dụ như chúng ta sử dụng Entity Framework Database First để tạo một DbContext mapping với Database. Đôi khi chúng ta cần tạo lại DbContext để cập nhật cấu trúc mới nhất của Database, lúc này DbContext của chúng ta sẽ được tạo lại từ đầu, đồng thòi sẽ xóa tất cả những sự bổ sung trước đó của chúng ta vào DbContext này và chúng ta phải viết lại các bổ sung. Nếu bạn không muốn làm điều đó thường xuyên thì Partial Class sẽ rất hữu dụng cho chúng ta.

Một số điều lưu ý về Partial Class:

- Chúng ta phải sử dụng từ khóa partial trong mỗi Partial Class.
- Các Partial Class phải có cùng mức độ truy cập (public, protected, private...).
- Các Partial Class nên có cùng namespace.
- Các Partial Class phải nằm trong cùng assembly hoặc cùng module (.exe hay .dll).
- Nếu một phần là abstract hay sealed thì những phần kia cũng phải được khai báo abstract hay sealed.
- Nếu một phần đã kế thừa từ class khác hay interfaces thì những phần khác cũng hiểu là đã kế thừa từ class hay interfaces đó, do đó bạn không cần phải kế thừa lại.

Trên đây là một vài chia sẻ của tôi về Partial Class. Nếu có gì thắc mắc hay trao đổi, các bạn có thể comment bên dưới bài viết này.

Share to be shared.

Tìm hiểu về lập trình hướng đối tượng

...đang được cập nhật

Design Patterns trong các dự án thực tế - Factory Pattern

Lời nói đầu

Trước khi tìm hiểu về Factory Pattern, hãy đọc lại bài viết Design patterns là gì nếu bạn vẫn chưa biết design patterns là gì. Ngoài ra để giúp bạn dễ dàng nắm bắt nội dung bài viết, hãy chắc là bạn đã biết về Lập trình hướng đối tượng (OOP) và các tính chất, khái niệm của nó như bao đóng (encapsulation), trừu tượng (abstract), kế thừa (inheritance), đa hình (polymorphism), đối tượng (object), lớp (class), giao diện (interface)...

***

Factory Pattern là gì?

Factory Pattern là một trong các pattern thông dụng nhất trong thiết kế phần mềm, thuộc nhóm creational pattern tức là thông qua pattern này để tạo ra đối tượng (object).

Factory pattern định nghĩa một giao diện (interface) hay một lớp cha (parent class) để tạo đối tượng (object) với các class con kế thừa từ interface hay class cha đó. Các class con này có thể tự quyết định cách thức hoạt động của mình. Ngoài ra có một Factory để tạo ra các class con này mà không cho bên ngoài biết cách thức tạo ra chúng.

Để dễ hiểu, chúng ta hãy thử liên tưởng đến việc sản xuất đồ uống của một nhà máy (factory) và chúng ta là những người sử dụng các sản phẩm (nước ngọt, bia, rượu...) của nhà máy đó. Chúng ta có thể đoán biết được việc sản xuất nước ngọt, bia... có thể cần nguyên liệu gì (đầu vào) nhưng chúng ta hoàn toàn không biết được làm thế nào mà nhà máy có thể sản xuất ra được thành phẩm (nước ngọt, bia, rượu). Đó chính là cách mà của Factory pattern hoạt động.

Áp dụng:

Kiên lấy lại ví dụ từ bài Design Patterns là gì: Hãy viết một chức năng kết nối database, mà chức năng này phải đảm bảo hoạt động tốt và dễ cấu hình cho các hệ quản trị cơ sở dữ liệu (DBMS) khác nhau như MySQL, MSSQL, Oracle. 

Như các bạn thấy, yêu cầu này muốn chúng ta tạo kết nối đến database dựa vào tham số đầu vào là MySQL, MSSQL hay Oracle và kết nối được tạo ra phải là một trong ba hệ quản trị cơ sở dữ liệu (DBMS) này. Với yêu cầu này, việc áp dụng Factory pattern sẽ được cân nhắc.

Để hiểu vì sao chúng ta lại áp dụng Factory Pattern trong ví dụ này, chúng ta thay đổi lại yêu cầu ban đầu: Hãy viết một chức năng kết nối database, mà chức năng này phải đảm bảo hoạt động tốt và dễ cấu hình cho MSSQL. Tức là yêu cầu ban đầu chỉ mong muốn chúng ta kết nối và hoạt động tốt với MSSQL - hệ quản trị cơ sở dữ liệu (DBMS) của Microsoft.

Yêu cầu khá dễ dàng đúng không? Trong ví dụ này Kiên sẽ sử dụng Entity Framework để tạo mapping đến cơ sở dữ liệu (database). Chi tiết về Entity Framework sẽ được giới thiệu trong các loạt bài sau.

Chúng ta cùng bắt đầu!

BƯỚC ĐẦU TIÊN: Sử dụng Entity Framework để tạo mapping từ database

Hãy tham khảo bài viết NÀY để tạo ra mapping cũng như connection string kết nối đến MSSQL thông qua mô hình Entity Framework - Database First.

BƯỚC TIẾP THEO: Tạo chuỗi kết nối kết nối tương ứng với MSSQL, MySQL, Oracle...

- Chúng ta đã hoàn thành yêu cầu đơn giản là tạo kết nối đến MSSQL. Hãy xem lại cách mà ConnectionString của chúng ta được tạo ra trong BÀI VIẾT NÀY

 public override string GetConnectionString()  
     {  
       SqlConnectionStringBuilder sqlBuilder = new SqlConnectionStringBuilder();  
       sqlBuilder.DataSource = @"VNWKTTV093\SQLEXPRESS";  
       sqlBuilder.InitialCatalog = "FactoryPattern";  
       sqlBuilder.MultipleActiveResultSets = true;  
       sqlBuilder.IntegratedSecurity = true;  
       sqlBuilder.ApplicationName = "EntityFramework";  
       EntityConnectionStringBuilder efBuilder = new EntityConnectionStringBuilder();  
       efBuilder.Metadata = "res://*/FactoryModel.csdl|res://*/FactoryModel.ssdl|res://*/FactoryModel.msl";  
       efBuilder.Provider = "System.Data.SqlClient";  
       efBuilder.ProviderConnectionString = sqlBuilder.ConnectionString;  
       return efBuilder.ConnectionString;  
     }  

- Nhưng yêu cầu ban đầu của chúng ta là phải kết nối được với 3 DBMS, vậy nếu chúng ta phải kết nối đến MySQL hay Oracle thì dễ thấy cách làm đơn giản nhất là chúng ta phải vào method GetConnectionString này và thay đổi các thông số như DataSource, Metadata, Provider... tương ứng với DBMS mà chúng ta cần kết nối...Quá trình này sẽ lặp đi lặp lại nếu chúng ta có nhiều dự án với yêu cầu các DBMS khác nhau. Điều này nghe có vẻ đơn giản nhưng nó sẽ tạo cho chúng ta thói quen không tốt khi phải sửa đi sửa lại các dòng code đã hoàn chỉnh của mình.

- Giải pháp khác là chúng ta thiết lập một DbType kiểu Enum bao gồm các loại DBMS mà chúng ta mong muốn kết nối, sau đó truyền biến này vào method GetConnectionString. Bên trong method sẽ xử lí kết nối thông qua switch..case hay mệnh đề if. Giải pháp này giải quyết được vấn đề bên trên, giúp chúng ta tránh phải thay đổi code theo thời gian. Nhưng nó cũng tồn tại một vấn đề là có quá nhiều việc phải làm bên trong class Connection này. Có quá nhiều lệnh switch..case hay if sẽ khiến cho class của chúng ta trở nên rối rắm, phức tạp. Giả sử class của chúng ta lớn, có nhiều xử lí...thì khi có bổ sung hay cập nhật sẽ khiến cho chúng ta rơi vào ma trận code, dễ xảy ra tình trạng râu ông này cắm cằm bà kia.

- Factory Pattern sẽ giải quyết được các vấn đề bên trên. Hãy xem sơ đồ UML bên dưới để hiểu cách mà Factory Pattern được áp dụng:


- Chúng ta hãy thay đổi class Connection lại một chút. Đầu tiên điều chỉnh class Connection là dạng abstract class, sau đó chúng ta cũng khai báo lại method GetConnectionString cũng là abstract method như hình 19. Điều này nhằm chỉ ra class Connection giờ đây là một class cha và không còn xử lí chung nữa, và các class con kế thừa phải tự thực thi lại theo cách riêng của chính nó.

(hình 19)

- Ta cũng tạo 3 class con là MSSqlConnection, MySQLConnection, OracleConnection kế thừa từ abstract class Connection này. Đồng thời override lại method GetConnectionString để xử lí. Khá rõ ràng và dễ dàng nếu chúng ta có cập nhật, bổ sung về sau.

MSSqlConnection.cs: chúng ta copy lại đoạn code lúc đầu để tạo ra ConnectionString cho MSSQL. Chúng ta cũng làm tương tự cho hai class còn lại và thay đổi các thông số cần thiết.

(hình 20)

MySqlConnection.cs

(hình 21)

OracleConnection.cs

(hình 22)

- Điều quan trọng tiếp theo là chúng ta phải có một Factory để tạo ra các Connection tương ứng. Ngoài ra để xác định loại Connection chúng ta cũng tạo một kiểu enum có tên DbType như hình 23.

- Thêm mới một class gọi là ConnectionFactory và một static method CreateConnection có tham số đầu vào là kiểu enum DbType, giá trị trả về là đối tượng thuộc class Connection. Bên trong method, chúng ta dựa vào dbType để trả về chính xác đối tượng thuộc class kết nối nào. Nếu dbType yêu cầu MSSQL thì chúng ta trả về đối tượng MSSqlConnection và tương ứng cho các dbType khác. Minh họa như hình 23.

(hình 23)

- Chúng ta cũng cập nhật đoạn code khởi tạo Connection trong sự kiện btnSearch_Click như hình 24 băng cách gọi hàm CreateConnection của ConnectionFactory và truyền tham số dbType mà ta mong muốn.

(hình 24)

- Run Debugging (F5) để đảm bảo mọi thứ vẫn hoạt động tốt. Các bạn có thể tạo các kết nối đến MySQL để kiểm tra thêm.

Như vậy là chúng ta đã xây dựng xong một cơ chế kết nối multi DBMS áp dụng Factory Pattern. Ví dụ trên cũng khá đơn giản nhằm mục đích giúp các bạn dễ hiểu hơn mà Kiên sẽ không đi sâu vào những vấn đề khác.

Ngoài ra để các bạn làm thử, Kiên có một ví dụ mở rộng khác là: Không throw exception mà hãy handle được các lỗi có thể xảy ra khi kết nối, tương tác database (CRUD) của 3 DBMS nói riêng và các exception nói chung và trả ra các mã lỗi tương ứng. Các bạn sẽ áp dụng Factory Pattern vào để xử lí yêu cầu này thế nào? Câu trả lời sẽ đến trong các bài tiếp theo.

Nếu có gì trao đổi hay thắc mắc, các bạn hãy để lại comment bên dưới dùm mình.

Share to be shared!

Bài tiếp theo - Singleton Pattern

Bài trước - Giới thiệu Design Patterns

Design Patterns trong các dự án thực tế - Design Patterns là gì?

Lời nói đầu

Chúng ta dễ dàng tìm thấy rất nhiều các tài liệu cũng như bài viết về design patterns trong sách vở, internet...Tuy nhiên vấn đề là những bài viết này khá chung chung, mang thiên hướng sách vở và không đưa ra được những ví dụ áp dụng thực tế trong công việc, dự án của chúng ta...Điều này khiến các developer cảm thấy khó hiểu và khó áp dụng để giải quyết các vấn đề trong công việc hàng ngày. Chính vì vậy Kiên viết loạt bài này dựa thêm kinh nghiệm thực tế trong các dự án mà Kiên đã tham gia để nhằm giới thiệu đến các bạn một số design patterns thông dụng nhất, dễ gặp nhất và các ví dụ về design patterns thực tế nhất nhằm giúp các bạn hiểu nhanh nhất, có thể biết được khi nào áp dụng, áp dụng ở đâu và làm thế nào để áp dụng nó vào công việc, dự án của mình.

***

Giới thiệu về Design Patterns.

Trước tiên ta cũng nên tìm hiểu Design Patterns là gì?

Design patterns có thể xem là một kĩ thuật lập trình hướng đối tượng (OOP) nâng cao, áp dụng một cách triệt để các tính chất của OOP như bao đóng (encapsulation), trừu tượng (abstract), kế thừa (inheritance), đa hình (polymorphism) cũng như các khái niệm như object, class, interfaces, generic...để đưa ra các mẫu thiết kế hoàn thiện. Hãy đảm bảo bạn đã nắm rõ hay ít nhất cũng có cái nhìn tương đối về OOP.
Bạn có thể tham khảo qua bài viết: Tìm hiểu về lập trình hướng đối tượng

Design patterns được giới thiệu và phát triển bởi các nhà phát triển phần mềm có kinh nghiệm, là những giải pháp cho những vấn đề chung mà các nhà phát triển phải đối mặt trong quá trình phát triển phần mềm. Những giải pháp này đã được tích lũy và đúc kết theo thời gian.

Một design pattern là một giải pháp chung cho một vấn đề thường xảy ra trong những tình huống nhất định. Nó mô tả hoặc làm mẫu để giúp ta làm thế nào để giải quyết một vấn đề mà có thể được sử dụng trong nhiều tình huống khác nhau.

Lấy ví dụ giả sử chúng ta có một yêu cầu: Hãy viết một chức năng kết nối database, mà chức năng này phải đảm bảo hoạt động tốt và dễ cấu hình cho các hệ quản trị cơ sở dữ liệu (DBMS) khác nhau như MySQL, MSSQL, Oracle...Lúc này ta có thể áp dụng ngay Factory Pattern để xử lí yêu cầu này.

Chúng ta có 3 nhóm design patterns và 23 design patterns cơ bản nhất:

Creational Patterns	Structural Patterns	Behavioral Patterns
Abstract Factory	Adapter	Chain of responsibility
Builder	Bridge	Command
Factory Method	Composite	Interpreter
Prototype	Decorator	Iterator
Singleton	Facade	Mediator
	Flyweight	Memento
	Proxy	Observer
		State
		Strategy
		Template Method
		Visitor

Trong khả năng và thời gian cho phép, Kiên sẽ cố gắng giới thiệu đến các bạn một số design patterns thông dụng nhất trong giải quyết các vấn đề cũng như trong thiết kế phần mềm.

Tại sao phải biết Design Patterns?

Như Kiên đã đề cập ở trên, design patterns được đúc kết bằng kinh nghiệm và là cách giải quyết chung cho các vấn đề trong thiết kế phần mềm. Chính vì vậy nếu chúng ta hiểu rõ design patterns thì khi chúng ta đối mặt một tình huống hay một vấn đề nào đó, chúng ta có thể áp dụng design patterns và vấn đề có thể được giải quyết một cách nhanh chóng và hiệu quả nhất.

Ngoài ra, nếu chúng ta áp dụng tốt design patterns, nó sẽ giúp giải pháp của chúng ta dễ hiểu, dễ trình bày, hệ thống của chúng ta linh hoạt, dễ bảo trì, dễ test hơn.

Đối với bản thân các developer, việc hiểu rõ design patterns sẽ giúp năng suất làm việc cải thiện, giá trị bản thân ngày càng tăng, đóng vai trò then chốt (key member) trong các dự án mà mình tham gia, đó cũng là đảm bảo cho quyền lợi, lợi ích của chúng ta sau này.

Ngoài ra chúng ta cũng biết ngành lập trình là ngành có mức độ phát triển, thay đổi khá nhanh, các công nghệ, ngôn ngữ, thư viện...cập nhật liên tục cũng sẽ khiến chúng ta phải liên tục cập nhật theo. Nhưng luôn có những giá trị cốt lõi trong bất kì ngành nghề nào, và OOP và design patterns chính là một trong các giá trị cốt lỗi trong lập trình, nó sẽ giúp bạn vững vàng và mạnh mẽ hơn trong thời đại công nghệ này.

Vậy ai là người nên biết về Design Patterns?

Design patterns được sử dụng rất rộng rãi trong thiết kế phần mềm, đôi khi chúng ta đã thật sự biết đến nó và áp dụng nó vào các dự án, vào code của mình mà không nhận ra, vì đôi khi đó là những design pattern rất đơn giản. Chính vì vậy, việc có cái nhìn tổng quát lại design patterns vô cùng bổ ích cho chúng ta - những developer.

Ngoài ra, trong thiết kế phần mềm nói chung và phát triển dự án nói riêng, việc tìm giải pháp và áp dụng design patterns thường được giao cho các key member, các senior developer. Do đó ngoài các senior developers cần củng cố kiến thức về design pattern, mà các junior developers, thậm chí là các bạn sinh viên, thực tập thì sự hiểu biết về design patterns là rất quan trọng và cần thiết để đóng vai trò quan trọng trong các dự án hay tổ chức mà mình tham gia.

Bên cạnh đó, việc thiết kế hệ thống áp dụng design patterns đôi khi cũng cần có sự tham gia của những nhà thiết kế, business analyst trong việc thiết kế, vẽ biểu đồ để từ đó hiện thực hóa chúng thành những dòng code. Dưới đây là một class diagram minh họa cho chức năng xử lí ngoại lệ (exception):

Design Patterns áp dụng khi nào và nơi đâu?

Như chúng ta đã biết, design patterns là những giải pháp cho những vấn đề của chúng ta trong việc lập trình, nên việc áp dụng design patterns là bất kể khi nào, bất kể nơi đâu miễn là chúng ta thấy nó giải quyết được vấn đề của mình.

Thay vì chúng ta tốn thời gian và chi phí để loay hoay tìm giải pháp, tìm người giúp đỡ thì có thể thông qua một hay nhiều design patterns nào đó, vấn đề sẽ được giải quyết một cách rất nhanh chóng và hiệu quả, giải pháp đưa ra cũng đạt sự đồng thuận, chấp nhận của mọi người.

Vậy học Design Patterns như thế nào?

Điều kiện tiên quyết để hiểu và áp dụng tốt design patterns là chúng ta phải có kiến thức về lập trình hướng đối tượng (OOP), các tính chất cũng như là các thành phần, khái niệm của OOP.
Nếu các bạn chưa nắm rõ OOP thì có thể xem lại bài viết: Tìm hiểu về lập trình hướng đối tượng

Sau đó các bạn có thể theo dõi các bài viết trên blog của Kiên để có cái nhìn tổng quan cũng như chi tiết về các design pattern thường gặp, từ đó có thể linh hoạt áp dụng vào các dự án mà mình đang tham gia. Cách khác là các bạn có thể tự mình xây dựng lại các chức năng nào đó thông qua các ví dụ rất thực thế mà Kiên đưa ra từ chính các dự án của mình.

Với một số design patterns mà Kiên không giới thiệu trong loại bài viết này, các bạn có thể tự mình tìm hiểu thêm trên sách vở, internet..., từ đó rút ra được kinh nghiệm cho riêng mình.

Song song đó chúng ta có thể cùng nhau trao đổi kiến thức thông qua blog này để không chỉ các bạn mà còn để chính bản thân Kiên ngày càng hiểu sâu và rộng hơn về design patterns.

Học bao nhiêu Design Patterns là đủ?

Như Kiên đã đề cập ở trên, chúng ta có 23 design patterns cơ bản được chia làm 3 nhóm. Sẽ rất tốt nếu các bạn có thể hiểu rõ tất cả nhưng trên thực tế sẽ có những design pattern ít khi được sử dụng. Trong giới hạn loạt bài viết này Kiên sẽ cố gắng giới thiệu đến các bạn càng nhiều càng tốt các design pattern mà Kiên đã từng gặp qua và áp dụng vào dự án thực tế của mình.

Ngoài ra nếu thời gian cho phép Kiên cũng sẽ giới thiệu đến các bạn một số design patterns khác không nằm trong 23 design patterns này nhưng hiện tại cũng được áp dụng khá nhiều như Repository Pattern, MVC Pattern...

---
P/S: Nếu các bạn có thắc mắc hay muốn trao đổi thêm, các bạn có thể comment trực tiếp bên dưới bài viết này.

Share to be shared

Bài tiếp theo - Factory Pattern