Lập trình với C#

Lập trình với C# ØChương 1 - Kiến trúc của C# và .NET ØChương 2 - Căn bản C# ØChương 3 - Hướng đối tượng trong C# ØChương 4 - Những chủ đề tiến bộ trong C# ØChương 5 - C# và các lớp cơ sở ØChương 6 - Lập trình trong môi trường .NET ØChương 7 - Windows Applications ØChương 8 - Assemblies ØChương 9 - Truy cập cơ sở dữ liệu với .NET ØChương 10 - Viewing .NET Data ØChương 11 - Thao tác XML ØChương 12 - File and Registry Operations ØChương 13 - Làm việc với Active Directory Biên dịch từ cuốn Professional C#, 2nd Edition, Xuất bản bởi Wrox Press Ltd .  Chương 1: C# và kiến trúc .NET Tổng quan: Tôi muốn nhấn mạnh rằng đừng bao giờ xem xét ngôn ngữ C# một cách tách biệt, nó luôn đồng hành với "Bộ khung .NET". C# là một trình biên dịch hướng .NET, nghĩa là tất cả các mã của C# luôn luôn chạy trên trên môi trường .NET Framework. Điều đó dẫn đến 2 hệ quả sau: Cấu trúc và các lập luận C# được phản ánh các phương pháp luận của .NET ngầm bên dưới. Trong nhiều trường hợp, các đặc trưng của C# thậm chí được quyết định dựa vào các đặc trưng của .NET, hoặc thư viện lớp cơ sở của .NET. Chính bởi tầm quan trọng của .NET, nên các bạn cần phải biết sơ qua về .NET trước khi đi vào ngôn ngữ C#. Đây cũng chính là mục đích của chương này. Chúng ta sẽ tìm hiểu xem chuyện gì sẽ xảy ra khi mã của các ngôn ngữ hướng .NET (bao gồm C#) được biên dịch và thực thi. Đây là một lĩnh vực rộng, chúng ta sẽ tìm hiểu kĩ hơn về Microsoft Intermediate Language (MS-IL), ngôn ngữ trung gian trong .NET mã của các ngôn ngữ khác đều phải được biên dịch về ngôn ngữ này trước khi thực thi. Cụ thể chúng ta sẽ tìm hiểu xem cách thức mà MS-IL với phần dùng chung Common Type System (CTS) và Common Language Specification (CLS) có thể cung cấp cho chúng ta sự tương hoạt giữa các ngôn ngữ hướng .NET. Chúng ta cũng sẽ trình bày các ngôn ngữ biết .NET khác bao gồm VB và C++. Sau đó chúng ta sẽ xem xét các đặc trưng khác của .NET, bao gồm các assembly, các namespace, và thư viện lớp cơ bản của .NET. Chúng ta sẽ kết thúc chương này bằng việc liệt kê vắn tắt về các loại ứng dụng mà chúng ta có thể tạo ra trong C#.  Mối quan hệ giữa C# và .NET C# là một ngôn ngữ lập trình mới, và được biết đến với hai lời chào: Nó được thiết kế riêng để dùng cho Microsoft's .NET Framework (Một nền khá mạnh cho sự phát triển, triển khai, hiện thực và phân phối các ứng dụng) Nó là một ngôn ngữ hoàn toàn hướng đối tượng được thiết kế dựa trên kinh nghiệm của các ngôn ngữ hướng đối tượng khác. Một điều quan trọng cần nhớ C# là một ngôn ngữ độc lập. Nó được thiết kế để có thể sinh ra mã đích trong môi trường .NET, nó không phải là một phần của .NET bởi vậy có một vài đặc trưng được hỗ trợ bởi .NET nhưng C# không hỗ trợ và bạn cũng đừng ngạc nhiên khi có những đặc trưng C# hỗ trợ mà .NET không hỗ trợ (chẳng hạn như quá tải toán tử) Để tạo được những ứng dụng mang tính hiệu quả cao, chúng ta sẽ xem qua về hoạt động của .NET Common Language Runtime Trung tâm của .NET framework là môi trường thời gian chạy, gọi là Common Language Runtime (CLR) hoặc .NET runtime. Mã của các điều khiển trong CLR thường là mã có quản. Tuy nhiêu, trước khi được thực thi bởi CLR, mã được phát triển trong C# (hoặc các ngôn ngữ khác) cần phải được biên dịch.Quá trình biên dịch trong .NET xảy ra theo hai bước: Dịch mã nguồn thành Microsoft Intermediate Language (MS-IL) Dịch IL thành mã nền cụ thể bởi CLR Mới nhìn có vẻ hơi dài dòng. Nhưng thật sự, một tiến trình dịch hai mức là rất cần thiết, bởi vì trạng thái của Microsoft Intermediate Language (mã có quản) là chìa khóa cung cấp nhiều lợi ích trong .NET. Các lợi ích của mã có quản Microsoft Intermediate Language (thường được viết tắt là"Intermediate Language", hay "IL") tương tự như ý tưởng về mã Java byte, nó là một ngôn ngữ cấp thấp với những cú pháp đơn giản (dựa trên cơ sở mã số hơn là text), chính điều này sẽ làm cho quá trình dịch sang mã máy nhanh hơn. Hiểu kĩ các cú pháp này sẽ mang lại những lợi ích đáng kể. Độc lập nền Trước tiên, nó có nghĩa là các file chứa mã lệnh có thể chạy trên bất kì nền nào, vào thời gian chạy trình biên dịch cuối sẽ hoạt động và mã có thể chạy trên một nền cụ thể. Nói cách khác việc dịch mã nguồn sang Intermediate Language cho phép độc lập nền trong .NET, nó giống như cách dịch mã nguồn sang Java byte code cung cấp sự độc lập nền trong Java. Bạn cũng nên biết rằng sự độc lập nền của .NET chỉ là trên lí thuyết bởi vì tại thời điểm này, .NET chỉ có sẵn trong Windows. Tuy nhiên việc chuyển .NET sang những nền khác đang được khảo sát tỉ mỉ (xem ví dụ Mono project, một sự cố gắng tạo một thực thi mã nguồn mở trong .NET, tại địa chỉ Sự cải tiến trong thực thi Mặc dù chúng ta đã so sánh với Jave, IL thật sự có một chút khả quan hơn Java. IL luôn là trình biên dịch Just-In-Time, ngược lại Java byte code thì thường là thông dịch. Một trong những bất lợi của Java là vào lúc thực thi quá trình dịch từ java byte code sang mã máy tốn nhiều tài nguyên. Thay vì phải dịch toàn bộ ứng dụng một lần, trình biên dịch JIT sẽ biên dịch từng phần mã khi nó được gọi. Khi mã được dịch rồi, mã kết quả sẽ được giữ lại cho tới khi thoát khỏi ứng dụng, chính vì thế nó không phải biên dịch lại trong lần chạy kế tiếp. Microsoft quả quyết rằng cách xử lí này có hiệu lực cao hơn là dịch toàn bộ ứng dụng, bởi vì có trường hợp một khối lượng lớn mã của ứng dụng không bao giờ được sử dụng trong thời gian chạy. Khi sử dụng trình biên dịch JIT , các đoạn mã này sẽ không bao giờ được dịch. Chính vì thế chúng ta hi vọng rằng mã IL sẽ thực thi nhanh như là mã máy. Microsof cam kết chúng ta sẽ có một thay đổi lớn trong thực thi. Lời lí giải là, là lần dịch cuối cùng trong thời gian chạy, trình biên dịch JIT sẽ biết chính xác loại vi xử lí mà chương trình sẽ chạy. Có nghĩa là nó có thể tối ưu mã thi hành cuối cùng bằng cách tham chiếu đến các đặc trưng của từng các bộ lệnh ứng với các loại vi xử lí đó. Các trình biên dịch truyền thống đều có tối ưu mã, nhưng chúng chỉ có thể tối ưu độc lập không quan tâm đến loại vi xử lý mà chương trình sẽ chạy. Bởi vì trình biên dịch truyền thống biên dịch toàn bộ ứng dụng sang mã máy trước khi thực thi. Có nghĩa là trình biên dịch không hề biết loại vi xử lí mà chương trình sẽ được chạy, chẳng hạn nó có thể là một vi xử lí tương thích x86 hoặc một vi xử lí Alpha. Visual Studio 6, tối ưu cho cho một máy tương thích Pentium, bởi vậy mã mà nó sinh ra không đem lại lợi ích gì đối với các đặc trưng phần cứng của vi xử lí Pentium III. Trong khi đó, trình biên dịch JIT có thể thực hiện tối ưu giống như Visual Studio 6, ngoài ra nó còn có thể tối ưu cho các loại vi xử lí cụ thể mà mã chương trình sẽ chạy. Tương hoạt giữa các ngôn ngữ Chúng ta đã biết cách thức IL cho phép độc lập nền, trình biên dịch JIT có thể cải thiện quá trình thực thi. Tuy nhiên, IL cũng làm cho tương hoạt giữa các ngôn ngữ trở nên dễ dàng hơn. Bạn có thể biên dịch IL từ một ngôn, và mã này sau đó có thể tương hoạt với IL được biên dịch bởi một ngôn ngữ khác. Bây giờ chắc bạn đang tự hỏi rằng những ngôn ngữ nào có thể tương tác với C# trong .NET, hãy xem qua các ngôn ngữ biết .NET phổ biến sau. VB.NET Visual Basic đã được tân trang lại để có thể tương thích với công nghệ .NET. Từ việc phát triển Visual Basic trong những năm gần đây cho thấy rằng trong các phiên bản trước, Visual Basic 6, nó không tương thích với lập trình .NET. Ví dụ, nó đặt nặng vấn đề tích hợp COM, và nó chỉ đưa ra các sự kiện để phát triển, hầu hết mã nền không có sẵn trong mã nguồn. Không những thế, nó không thực sự hỗ trợ tính thừa kế và các kiểu dữ liệu chuẩn của Visual Basic không tương thích với .NET. Visual Basic đang được hoàn thiện trong Visual Basic .NET, cũng đừng ngạc nhiên khi sự thay đổi này xảy ra trên một diện rộng. Về phương diện thực hành bạn có thể xem VB.NET như là một ngôn ngữ mới. Mã VB 6 không không thể được biên dịch trong như mã VB.NET. Sự chuyển đổi từ lập trình VB 6 sang VB.NET yêu cầu một sự thay đổi lớn về mã. Tuy nhiên hầu hết các sự thay đổi này có thể được thực hiện một cách tự động bởi Visual Studio .NET (sự cải tiến của VS cho việc sử dụng .NET). Nếu bạn cố gắng đọc một đề án VB 6 trong Visual Studio .NET, nó sẽ cải tiến đề án của bạn, có nghĩa là nó sẽ viết lại mã nguồn VB 6 thành mã nguồn VB.NET. Điều đó có nghĩa là việc này sẽ gặp rắc rối khi bạn cắt ngang, bạn sẽ phải kiểm tra lại mã VB.NET mới để chắc rằng đề án của bạn vẫn chạy đúng. Một hiệu ứng phụ là không còn khả năng biên dịch .NET sang mã thực thi. VB.NET chỉ biên dịch sang IL, giống như C#. Nếu như bạn muốn tiếp tục mã hóa trong VB 6, bạn có thể làm như vậy, nhưng khi mã thực thi quá dài nó sẽ lờ đi .NET Framework, và bạn cần phải giữ lại Visual Studio 6 đã cài đồng thời phải hoàn toàn tin vào môi trường phát triển trong Visual Studio. Managed C++ Vào lúc đó trong Visual C++ 6, C++ đã có một khối lượng lớn các mở rộng của Microsoft trong Windows. Với Visual C++ .NET, các mở rộng này được tăng thêm cho việc hỗ trợ .NET framework. Có nghĩa là mã nguồn C++ sẽ vẫn tiếp tục được dịch sang mã máy không có gì khác biệt. Cũng có nghĩa là nó sẽ chạy độc lập trong môi trường .NET. Nếu bạn không muốn mã C++ của bạn chạy trong môi trường .NET Framework, bạn có thể đơn giãn đặt dòng lệnh sau vào đầu mã nguồn của bạn: #using Bạn cũng có thể bỏ qua cờ /clr trong trình biên dịch, cờ này cho biết rằng bạn muốn biên dịch sang mã có quản, và nó sẽ phát ra IL thay vì mã máy. Có một điều thú vị trong C++ khi bạn biên dịch sang mã có quản, trình biên dịch có thể phát ra các IL có nhúng các mã máy. Điều này có nghĩa là bạn có thể pha trộn kiểu có quản và kiểu không quản trong mã C++. Bằng cách mã C++: class MyClass { Định nghĩa cho một lớp trong C++ , trong khi đó mã: __gc class MyClass { sẽ cho bạn một lớp có quản, giống như việc bạn viết một lớp trong C# hay VB.NET. Thật vậy, một thuận lợi của managed C++ so với C# là bạn có thể gọi các lớp không quản C++ từ mã có quản C++ bỏ qua tương thích COM. Trình biên dịch sẽ phát ra một lỗi nếu bạn cố gắng dùng những đặc trưng mà mã có quản của .NET không hỗ trợ trong (ví dụ, khuôn mẫu hay đa thừa kế). Bạn cũng sẽ nhận ra rằng bạn sẽ phải dùng các đặc trưng không thuần C++ (chẳng hạn từ khoá __gc trong ví dụ trên) khi sử dụng các lớp có quản. Bởi vì trong VC++ cho phép giải phóng bộ nhớ thủ công dưới dạng một con trỏ, trình biên dịch C++ không thể phát ra mã cho kiểu bộ nhớ an toàn CLR. Nếu ứng dụng của bạn thật sự cần phải nhận dạng kiểu bộ nhớ an toàn CLR, bạn cần phải viết mã nguồn trong các ngôn ngữ khác (như C# hay VB.NET). J++ and J# J++ vẫn được hỗ trợ cho chỉ vì mục đích tương thích trước đây. Microsoft không còn phát triển bất kì nền tảng nào hỗ trợ việc biện dịch sang máy Java ảo. Thay vì đó, Microsoft phát triển hai công nghệ tách biệt Java/J++ phát triển bên dưới ngọn cờ JUMP (Java User Migration Path) và "JUMP trong .NET". Công nghệ đầu tiên là Visual J#. Về bản chất nó được thêm vào Visual Studio.NET để cho phép bạn viết và biên dịch mã J++. Sự khác biệt đó là thay vì biên dịch sang một Java Virtual Machine, J# sẽ biên dịch sang IL, vì vậy nó sẽ hoạt động như là một ngôn ngữ của .NET. Ngừơi dùng J# sẽ có thể được hưởng các thuận lợi của các đặc tính của VS.NET. Microsoft tin răng người dùng J++ sẽ nhanh chóng nhận ra điều đó nếu họ thích làm việc trong với .NET. Sự lựa chọn thứ hai là công cụ tự động hỗ trợ việc chuyển mã J++ sang mã C#. Sự giống nhau giữa J++ và C# làm cho việc chuyển đổi này trở nên dễ dàng hơn. Không giống như J# cũng không như các công cụ chuyển đổi ngôn ngữ có sẵn như là một phần của .NET hay trong Visual Studio. NET, thay vì thế nó được cung cấp riêng. Để biết thêm thông tin liên hệ Scripting languages Scripting languages đâu đó vẫn còn tồn tại, dù rằng về mặt tổng quát, tầm quan trọng của chúng đã giảm sút cùng với sự ra đời của .NET. JScript, được cải tiến lên JScript.NET. ASP.NET (một cải tiến từ ASP dành cho .NET, giải thích sau) các trang có thể được viết bằng JScript.NET, và bây giờ nó có thể chạy trên JScript.NET như là một ngôn ngữ biên dịch hơn là một ngôn ngữ thông dịch và nó có thể tạo ra các mã kiểu mã JScript.NET mạnh hơn. Với ASP.NET không có lí do gì để dùng scripting languages trên cac trang web server-side. VBA vẫn được sử dụng như là một ngôn ngữ cho Microsoft Office và Visual Studio macros. COM and COM+ COM và COM+ không là công nghệ chính của .NET, bởi vì các thành phần cơ bản của chúng không thể dịch sang IL (mặc dù vẫn có thể làm điều đó khi tổ chức thành phần COM bằng mã C++). Tuy nhiên COM+ vẫn còn là một công cụ quan trọng, từ khi đặc tính của nó được nhân lên trong .NET. Ngoài ra, thành phần COM vẫn còn làm việc và .NET kết hợp chặc chẽ các đặc trưng tương hoạt COM để mã có quản có thể gọi đến COM và ngược lại (sẽ được bàn thêm ở chương 17). Assemblies Một assembly là một đơn vị luận lí chứa mã đã được biên dịch sang .NET. Chúng ta sẽ bàn kĩ về các assemblie trong chương 8, ở đây chúng ta sẽ nói sơ về nó. Một assembly là một tự mô tả đầy đủ, và nó giống một đơn vị luận lí hơn là một đơn vị vật lí, điều đó có nghĩa là nó có thể chứa trong nhiều file (thật vậy các assemblie động được lưu trong bộ nhớ không phải trong file). Nếu một assembly được lưu trong nhiều file, thì sẽ có một file chính chứa các con trỏ và các mô tả về các file khác của assembly. Chú ý rằng, câu trúc assembly được dùng chung cho cả mã thi hành và mã thư viện. Sự khác biệt duy nhất là assembly thi hành chứa lối vào chương trình chính trong khi assembly thư viện thì không có. Một điểm quan trọng trong các assembly là chúng chứa metadata dùng để mô tả các kiểu và phương thức được định nghĩa trong mã tương ứng. Một assembly, tất nhiên cũng chứ assembly metadata dùng để mô tả chính assembly đó. Assembly metadata này, chứa một vùng đựơc hiểu như là manifest, cho phép kiểm tra phiên bản và tình trạng của assembly. ildasm, một tiện ích có sẵn của Windows, có thể dùng để nghiên cứu nội dung của một assembly, bao gồm manifest metadata. Chúng ta sẽ lấy vi dụ về ildasm trong chương 8. Thật vậy một assembly chứa metadata của chương trình nghĩa là các ứng dụng hoặc các assembly khác có thể gọi mã trong môt assembly mà không cần tham chiếu đến Registry, hoặc một dữ liệu nguồn khác,. Một điểm quan trọng trong cách làm của COM cũ, các GUID của các thành phần và giao diện interfaces không thể đạt được từ Registry. Việc dàn trải dự liệu thành 3 định vị khác nhau đồng nghĩa với việc tạo ra mối nguy hiểm trong đồng bộ hoá, nó ngăn không cho các thành phần khác sử dụng. Với assemblies, sẽ không còn những mối nguy hiểm như vậy, bởi vì tất các các metadata được lưu trong bộ lệnh thi hành của chương trình. Chú ý rằng dù cho các assemblie được lưu thành một vài file, chúng vẫn không gây vấn đề gì về đồng bộ hoá dữ liệu. Đó là vì nhờ vào file assembly chính, file này chứa đường dẫn, các thông tin chi tiết, mã băm, và nội dung của các file khác, điều đó có nghĩa là nếu một file bị thay thế, hay bị phá hoại, nó sẽ được tìm ra và sẽ không cho load. Assemblies bao gồm 2 loại: các shared và private assembly. Private Assemblies Private assemblies là kiểu đơn giản nhất. Nó chứa phần mềm và chỉ được dùng cho phần mềm đó. Với phần mô tả này bạn có thể chứa đựng các private assemblie hòng cung cấp cho một ứng dụng kiểu thực thi và một số thư viện, các thư viện này chứa mã sẽ được thi hành bởi ứng dụng đó. Hệ thống đảm bảo rằng private assemblies sẽ không được dùng bởi phần mềm khác, bởi vì một ứng dụng chỉ có thể load private assemblies trong cùng folder với chương trình chính hoặc là trong một thư mục con của nó. Chúng ta không thể tin cậy rằng tất cả các phần mềm luôn được cài đặt trong thư mục của nó, nghĩa là sẽ không bao giờ có chuyện một gói phần mềm ghi đè, sửa chữa hoặc vô tình load một private assemblies dành riền cho một gói khác. Vậy làm sao để các Private assemblie chỉ được dùng bởi gói phần mềm mà nó mô tả? Cần có một cơ chế bảo vệ, sao cho khi một sản phẩm thương mại khác cài đè lên một phiên bản assembly mới (chưa kể đến các chương trình đựơc thiết kế để phá hoại), thì sẽ không có chuyện tranh chấp tên. Nếu có sự trùng tên trong các assembly, đều đó không quan trọng và các ứng dụng chỉ có thể nhìn thấy một bộ các assembly. Bởi vì một private assembly là một tự định nghĩa trọn vẹn, tiến trình xử lí cực kì đơn giản. Bạn đơn giản thay thế các file thích hợp vào thư mục thíhc hợp trong file hệ thống (Không cần phải đăng kí trong registry). Tiến trình này được gọi là zero impact (xcopy) installation. Shared Assemblies Shared assemblies được dành cho cácc thư viện công cộng có thể dùng cho bất kì ứng dụng nào. Bởi vì bất kì ứng dụng nào cũng có thể truy xuất một shared assembly, cần phải có các cơ chế để bảo vệ các rủi ro sau: Tranh chấp tên, khi một công ty tạo ra các shared assembly trùng tên với các shared assembly sẵn có của bạn. Về mặt lí thuyết mã của bạn có thể truy xuất vào cả hai assembly này song đây có thể là một vấn đề phức tạp. Lỗi của một assembly có thể bị ghi đè bởi một phiên bản khác của cùng same assembly - một phiên bản mới không tương thích với những gì sẵn có. Giải pháp cho những vấn đề trên là đặt các shared assembly trong một cây thư mục đặt biệt của hệ thống, có thể xem như là assembly cache toàn cục. Không giống như các private assembly, nó không đơn giản là copy assembly sang một thư mục thích hợp - nó cần được cài đặt rõ ràng vào cache. Tiến trình này có thể được thực thi bởi một số tiện ích của .NET, bao gồm luôn quá trình kiểm tra trên assembly, tương tự như cài đặt một thư mục trong assembly cache để đảm bảo tính toàn vẹn của assembly. Để tránh tranh chấp tên, shared assemblies đưa ra một được quản lí dựa trên một khóa mật mã chính. Tên này được gọi là strong name, được bảo đảm về tính độc nhất, và phải được trích dẫn bởi ứng dụng muốn tham chiếu đến một shared assembly. Vấn đề về tương thích với lỗi do ghi đè một assembly được đánh địa chỉ theo thông tín phiên bản trong assembly manifest, và cho phép cài đặt song song. Reflection Từ khi các assembly được lưu dưới dạng metadata, bao gồm chi tiết về tất cả các kiểu và thành viên của những kiểu này, thì nó có thể được truy xuất được các metadata programmatically. Để biết chi tiết hơn, xin hãy xem reflection - mã quả có thể xem xét các mã quản khác, hoặc xem xét chính nó, để nhận ra các thông tin về mã. Bạn có thể dùng các attribute, để có thể sử dụng phương thức trong lúc chạy điều này tốt hơn là trong lúc biên dịch. Tìm hiểu về Intermediate Language Như chúng ta đã biết, Intermediate Language hoạt động như là bản chất của .NET Framework. Là lập trình viên C#, chúng ta nên biết rằng mã C# sẽ luôn được dịch sang Intermediate Language trước khi nó được thực thi (thật vậy, trình biên dịch C# chỉ dịch sang mã có quản). Chúng ta hãy cùng khám phá các tính năng chính của IL, bất kì ngôn ngữ nào hướng .NET cũng sẽ hỗ trợ các đặc tính chính của IL. Sau đây là những đặc tính chính của Intermediate Language: Hướng đối tượng và dùng interfaces Sự tách biệt giữa kiểu giá trị và kiểu tham chiếu Định kiểu mạnh Quản lỗi thông qua các ngoại lệ Sự dụng các thuộc tính Bây giờ chúng ta sẽ cùng khám phá các đặc tính trên. Hỗ trợ hướng đối tượng và dùng giao diện Ngôn ngữ độc lập nền của .NET có một vài giới hạn riêng. Cụ thể trong lúc thực thi IL chắc chắn sẽ thực thi một cách thức lập trình riêng, và các ngôn ngữ khác phải chú ý đến việc tương thích với cách thức lập trình này. IL đã được Microsoft phát triển như là một ngôn ngữ hướng đối tượng cổ điển hỗ trợ đầy đủ thừa kế đơn giữa các lớp. Bên cạnh lập trình hướng đối tượng đơn, Intermediate Language còn nêu ra ý tưởng về interfaces (giao diện), cái đã được tích hợp trong Windows với giao diện COM. .NET nó không giống như giao diện COM; chúng không cần phải hỗ trợ bất kì một kiến trúc COM nào (ví dụ, chúng không xuất phát từ IUnknown, và chúng cũng không liên quan gì đến các GUID). Tuy nhiên chúng có thể dùng chung các giao diện COM. Hướng đối tượng và thực thi chéo ngôn ngữ Bây chúng ta sẽ tìm hiểu về hoạt động của .NET nghĩa là hoạt động bi