Như bạn đã biết trong bài trước, Entity Framework code-first có khả năng tự động tạo cơ sở dữ liệu và bảng dữ liệu từ class C#. Người lập trình hầu như không cần can thiệp vào quá trình này.
Để thực hiện quá trình tự động đó, Entity Framework sử dụng cơ chế “cấu hình dựa trên quy ước” (configuration over convention). Theo cơ chế này, nếu bạn sử dụng một số lối viết (ví dụ, cách đặt tên) theo quy ước của Entity Framework, bạn sẽ không cần tự mình cấu hình. Entity Framework sẽ sử dụng quy ước đó để tự động cấu hình.
Ngoài ra Entity Framework cung cấp hai phương pháp khác để thực hiện cấu hình “thủ công”: (1) dùng data annotation attribute; (2) sử dụng fluent API qua class DbModelBuilder.
Trong bài học này, chúng ta sẽ cùng xem xét các quy ước cơ bản nhất của code-first dùng trong quá trình ánh xạ class (và các property) thành bảng (và cột) CSDL. Hai phương pháp cấu hình còn lại sẽ được xem xét trong từng bài học riêng.
[signinlocker id=”16252″]
Các quy ước cơ bản trong Entity Framework
Domain class, bảng CSDL và schema
Mặc định Entity Framework sẽ ánh xạ mỗi domain class sang một bảng CSDL nếu trong lớp context có property DbSet<> tương ứng. Ví dụ, nếu bạn có class Person và trong lớp Context có khai báo property public DbSet<Person> People {get; set;} thì class này sẽ được ánh xạ thành một bảng CSDL.
Entity Framework tự động “pluralize” tên class để làm tên bảng dữ liệu. “Pluralize” tuân thủ quy tắc chuyển danh từ sang số nhiều của tiếng Anh. Nếu bạn đặt tên bằng ngôn ngữ khác, pluralize chỉ đơn giản là thêm “s” vào sau tên class để tạo thành tên bảng.
Ví dụ, nếu class có tên là Person thì Entity Framework sẽ ánh xạ nó thành bảng People.
Mặc định, Entity Framework luôn tạo bảng dữ liệu trong schema dbo. Nếu muốn tạo bảng trong schema khác, bạn sử dụng attribute Table.
Nếu muốn đặt tên bảng và schema không theo quy tắc trên, bạn có thể sử dụng attribute Table hoặc phương thức ToTable của fluent API.
Tên khóa chính
Entity Framework quy ước tên khóa chính của bảng có thể ở hai dạng: Id, và <Tên class>Id. Nghĩa là, nếu trong class có trường kiểu int tên Id hoặc <Tên class>Id, Entity Framework sẽ sử dụng trường này làm khóa chính (Primary Key, PK) của bảng tương ứng.
Mặc dù quy ước trên không phân biệt chữ hoa – thường, C# lại có quy ước đặt tên property theo dạng PascalCase. Do vậy bạn luôn nên đặt tên khóa chính là Id hoặc <Tên class>Id.
Ví dụ, với class Person thì tên khóa chính là Id hoặc PersonId.
Property và cột CSDL
Mặc định Entity Framework sẽ ánh xạ tất cả property của domain class thành các cột của bảng CSDL.
Tên property của class được sử dụng làm tên cột của bảng CSDL.
Thứ tự của cột trong bảng CSDL giống như thứ tự của property đó trong class.
Kiểu của property được ánh xạ thành kiểu của SQL Server theo bảng quy tắc bạn sẽ xem ở phần tiếp theo của bài học.
Nếu property thuộc kiểu reference hoặc nullable, cột tương ứng của nó được đánh dấu NULL (cho phép để trống không chứa giá trị). Nếu property thuộc kiểu value, nó sẽ ánh xạ sang cột NotNull (bắt buộc phải có giá trị).
Dưới đây là một ví dụ minh họa cơ chế ánh xạ mặc định theo quy ước trên:
Ánh xạ kiểu của Property sang kiểu của cột
Kiểu của .NET và kiểu của SQL Server
Entity Framework code-first chia các property của model class thành hai loại: simple property (thuộc tính đơn giản) và complex property (thuộc tính phức tạp).
Thuộc tính đơn giản là những thuộc tính có kiểu cơ bản trong .NET mà có thể trực tiếp ánh xạ sang kiểu của SQL. Thuộc tính phức tạp có kiểu là các struct hoặc class do người dùng tự định nghĩa. Hai loại property này có cách thức ánh xạ sang CSDL khác nhau.
Do có sự vênh nhau giữa kiểu dữ liệu của .NET và SQL Server, Entity Framework cố gắng giải quyết vấn đề này bằng cách đưa ra một bảng ánh xạ giữa chúng. Nắm được vấn đề này sẽ giúp bạn kiểm soát tốt hơn quá trình xây dựng class model.
Bạn cũng lưu ý sự tương quan giữa kiểu của .NET và kiểu của C#. Ví dụ Int32 chính là int của C#, String chính là string của C#, Boolean chính là bool của C#. Nói cách khác, kiểu của C# là một dạng alias của kiểu tương ứng trong .NET.
Các property có kiểu nằm trong danh sách trên được xem là “đơn giản”, nhằm phân biệt với các property có kiểu phức tạp (complex type property) sẽ xem xét ở một bài học riêng.
Vấn đề khó khăn trong ánh xạ kiểu
Đối với mỗi kiểu dữ liệu .NET sẽ có những khó khăn (vênh) riêng khi ánh xạ sang kiểu của SQL Server). Việc quyết định kiểu cụ thể nào của SQL Server khi tạo bảng rất quan trọng vì nó ảnh hưởng trực tiếp đến hiệu suất lưu trữ và tính toán.
Giả sử trong class của bạn có một thuộc tính kiểu string. Như đã thấy trong bảng ánh xạ trên, string của C# (hay String của .NET) có thể ánh xạ sang nhiều kiểu văn bản khác nhau của Sql Server.
Tuy nhiên, vấn đề ở chỗ mỗi RDBMS có nhiều cách lưu trữ văn bản khác nhau. Ví dụ, văn bản của các ngôn ngữ khác tiếng anh thường cần lưu trữ ở dạng Unicode (nchar, nvarchar), trong khi văn bản tiếng anh có thể dùng char hoặc varchar. Nếu số lượng ký tự của một cột là không đổi, ví dụ, mã sinh viên, có thể chỉ cần dùng char thay vì varchar.
Để chỉ định chính xác kiểu cụ thể mình mong muốn, bạn nên sử dụng attribute hoặc fluent API thay vì dựa dẫm vào quy ước.
Quy ước ánh xạ mặc định
Nếu bạn không chỉ định bất kỳ cấu hình nào khắc, mặc định Entity Framework sẽ thực hiện ánh xạ kiểu của C# sang kiểu của Sql Server theo bảng dưới đây.
| Kiểu C# | Kiểu của SQL Server |
|---|---|
| int | int |
| string | nvarchar(Max) |
| decimal | decimal(18,2) |
| float | real |
| byte[] | varbinary(Max) |
| datetime | datetime |
| bool | bit |
| byte | tinyint |
| short | smallint |
| long | bigint |
| double | float |
| char | No mapping |
| sbyte | No mapping (throws exception) |
| object | No mapping |
Xử lý tình huống NULL và NOT NULL
SQL Server cho phép một trường dữ liệu có thể nhận giá trị null, với ý nghĩa rằng ô tương ứng có thể “không chứa giá trị”. Ví dụ, một trường số nguyên của bảng nếu được đánh dấu “null” (đặt từ khóa NULL sau khai báo của trường), ô tương ứng của nó có thể không chứa giá trị.
Entity Framework quyết định xem một trường liệu có thể NULL dựa trên kiểu của property.
Đối với các kiểu reference type (như string), biến của chúng có thể nhận giá trị null. Do đó, trường tương ứng của bảng tự động được đánh dấu NULL.
Đối với kiểu value type (int, bool, double, DateTime, v.v.), biến của chúng không thể nhận giá trị null. Do đó, trường tương ứng của bảng không được đánh dấu NULL.
Các kiểu dữ liệu của .NET được phân làm hai loại: value type, reference type. Enum, struct thuộc value type; class, interface, delegate thuộc reference type.
Để tương thích với các trường NULL của SQL Server, .NET sử dụng các nullable type để thể hiện những tình huống tương tự. Nullable type cho phép một biến thuộc các kiểu value type (như int, bool, char, v.v.) có thể nhận giá trị null, tức là trạng thái “không có giá trị”.
Khi cấu hình entity class, bạn có thể cho phép một trường tương ứng của property (kiểu nullable type) nhận giá trị null bằng cách đặt thêm dấu hỏi chấm ? phía sau tên kiểu. Cách viết này yêu cầu Entity Framework đánh dấu trường tương ứng trong bảng là NULL.
Convention: ký tự ? đứng sau tên kiểu (value type) cho phép trường tương ứng nhận giá trị null.
Ví dụ:
public DateTime? BirthDate { get; set; }
public int? Age { get; set; }Khi này, trường BirthDate và Age tương ứng của bảng dữ liệu sẽ được đánh dấu “NULL”, tức là có thể không chứa dữ liệu. Khi đó, BirthDate và Age của entity nhận giá trị null tương ứng.
Kết luận
Bài học này đã cung cấp cho bạn những nội dung cơ bản về quy ước cấu hình trong Entity Framework code-first. Bạn cũng nắm được cách thức chung để ánh xạ kiểu của C# (và .NET) sang kiểu của SQL Server.
Bạn có thể thấy các quy ước này rất đơn giản và khá tự nhiên. Bạn sẽ không gặp khó khăn gì khi khi nhớ và làm việc với nó. Đây cũng là cách thức đơn giản nhất để làm việc với Entity Framework qua tiếp cận code-first.
Trong các bài học tiếp theo bạn sẽ lần lượt đi vào cách thức cấu hình thủ công với annotation attribute hoặc fluent API để có thể kiểm soát tốt hơn quá trình ánh xạ này.
+ Nếu bạn thấy site hữu ích, trước khi rời đi hãy giúp đỡ site bằng một hành động nhỏ để site có thể phát triển và phục vụ bạn tốt hơn.
+ Nếu bạn thấy bài viết hữu ích, hãy giúp chia sẻ tới mọi người.
+ Nếu có thắc mắc hoặc cần trao đổi thêm, mời bạn viết trong phần thảo luận cuối trang.
Cảm ơn bạn!
[/signinlocker]
