代码第一：流畅api影响UI？ [英] Code first: does fluent api influence UI?
问题描述
我知道注释允许配置代码如何首先生成数据库对象以及MVC如何自定义UI元素。假设我使用[Required，MaxLength（50）]。该属性将在数据库中生成一个NOT NULL，nvarchar（50）。它还将验证该字段的输入。
[必需，MaxLength（50）]
public string Name {get;组; }
如果我决定使用Fluent API首先配置代码，该怎么办？我仍然需要注释来影响UI元素或使用流畅的API是否足够？
编辑
注释如何，目的是什么？他们有等价物吗？如果没有，我需要使用annotaions？
[显示（名称=出生日期）]
public DateTime BirthDate {get;组;
感谢您的帮助
数据注释是告诉类强制执行一些验证规则的最简单的方法。您也可以使用Fluent API做同样的事情。有些人喜欢通过数据注释来做这些事情，有些人喜欢使用流畅的API。
喜欢数据注释的原因
1）将实体的确认信息与实体定义一起保存在一个位置
喜欢的原因它与Fluent API
1）保持我的实体清洁。它将只有我的财产信息。没有验证信息。清洁简单的POCO。我将在数据上下文类中的 OnModelCreating 方法上写入验证。
您不能执行所有Fluent API事情与数据注释方式。与Fluent API方式（Ex：HasMinLength）不相同的数据注释属性相同。 HasMinLength 是我们的模型验证的一部分，通常在UI中是有意义的。
对于UI模型验证，您不能单独使用Fluent API。 Fluent API的主要作用是研究我们编写的流畅配置，并在从实体创建模型（数据库）时执行。 请记住，我们正在覆盖 OnModelCreating 方法来编写流畅的API配置。所以对于UI验证（我的ViewModel），我将使用DataAnnotation方法并使用流畅的API，如果我想定义一些与我的数据模型相关的东西，如定义一个外键或将该实体映射到具有不同名称的表等。
编辑：根据问题编辑，
您应该使用在这种情况下的数据注释。如果你先做代码您可能会记得该实体将成为您的数据库表（当然，您可以告诉EF忽略/重命名特定的列）。在这种情况下，我将保持我的实体清洁并创建一个 ViewModel ，我将在我的UI中使用。我将在我的 ViewModel 中添加我的 DataAnnotations 来处理它。我可以编写一些映射代码，可以在必要时将数据从ViewModel映射到模型和模型到ViewModel。
I'm reading a book written by Julie Lerman on Code First. According to the book, annotations and fluent api give the same result. Everything depends on the style of the developer.
I know that annotations allow both to configure how code first generate database objects and how MVC customize UI elements. Let's say I use [Required, MaxLength(50)]. The attribute will generate a NOT NULL, nvarchar (50) in the database. It also will validate the input for that field.
[Required, MaxLength(50)]
public string Name { get; set; }
What if I decide to use Fluent API to configure Code first. Am I still going to need annotations to influence UI elements or using fluent API is going to be enough?
EDIT
How about annotations, such as Display that serve only for UI purposes? Do they have equivalents? If not, Will I need to use annotaions?
[Display(Name = "Date of Birth")]
public DateTime BirthDate { get; set; }
Thanks for helping
Data Annotation is the simplest way of telling a class to enforce some validation rule. You can do the same thing with Fluent API as well. Some people like doing it by data annotations and some people like it by doing with fluent API
Reasons to like it with Data Annotations
1) Keep the validation info about my entity in one place along with the entity definition
Reasons to like it with Fluent API
1) Keep my entity clean. It will have only my property info. No validation info. Clean and simple POCO. I will write validation on the OnModelCreating method in my data context class.
You can not do all Fluent API things with Data Annotations way. the same way you don't have few Data Annotations attributes equivalant not present with Fluent API way ( Ex : HasMinLength) . HasMinLength is something we will for our Model validation which usually makes sense in the UI.
For the UI Model Validation, you can not use the Fluent API alone. Fluent API's major role is to look into the fluent configuration we writes and act when creating the Model(Database) from the entities. Remember we are overriding the OnModelCreating method to write our fluent API configuration. So for the UI Validation (of my ViewModel), I would use the DataAnnotation way and use fluent API if i want to define some thing related to my datamodel like Define a foreign key or Map this Entity to a Table with different name etc..
EDIT : As per the question edit,
You should make use of the Data Annotations in this case. If you are doing code first. You may remember that that entity is going to be your Database table ( of course you can tell EF to ignore /rename specific columns). In that case, I would keep my Entities clean and Create a ViewModel which i will use in my UI. I will add my DataAnnotations in my ViewModel to handle it. I may write some mapping code which maps data from ViewModel to Model and Model to ViewModel wherever necessary.
这篇关于代码第一：流畅api影响UI？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
