Las mejores prácticas de desbordamiento de Entity Framework y SqlDateTime

Question

System.DateTime pueden tomar un rango más amplio de valores que DateTime de SQL Server. Por lo tanto, existe la clase System.Data.SqlTypes.SqlDateTime que imita a la posterior.

En consecuencia, esperaba que Entity Framework eligiera SqlDateTime, pero no fue así.

Así que mis preguntas son ...

¿Cuáles son las mejores prácticas para asegurar que sus valores DateTime no causarán problemas cuando intenta guardarlos en su base de datos?

¿Hay alguna forma de forzar a EF a usar SqlDateTime?

Answer 1

Hay una serie de cosas que puede hacer:

• si está utilizando SQL Server 2008 o posterior, puede utilizar los DATE o DATETIME2 tipos de datos en la base de datos que ofrece el mismo rango de fechas como de .NET DateTime

• si no puede usar esos nuevos tipos de datos, será hasta usted para manejar alguna comprobación/validación en sus campos de fecha antes de que las cosas están siendo almacenados en el almacén persistente. EF EntityObject ofrece un montón de maneras de aprovechar el proceso de validar y guardar objetos - elegir un método que funciona para usted

Answer 2

Más específicamente, intenta esto: http://www.vfstech.com/?p=111

Answer 3

Tal vez este es un viejo hilo, pero me publicará mis hallazgos en esto por los demás:

Let decir que tenemos env dev: EF 5, CodeFirst, SQLCE 4.0:

public abstract class Entity : IEntity, IEquatable<Entity> 
{ 
public virtual int Id { get; protected set; } 
public virtual DateTime LastModified { get; set; } 

[DataType(DataType.Date)] 
public virtual DateTime CreatedOn { get; set; } 

[DataType(DataType.DateTime)] 
public virtual DateTime CreatedOn2 { get; set; } 

[DataType(DataType.Time)] 
public virtual DateTime CreatedOn3 { get; set; } 

public virtual DateTime CreatedOn4 { get; set; } 
} 

wi º un mapeo tal costumbre:

public EntityMapping() 
{ 
HasKey(e => e.Id); 
Property(e => e.Id); 
Property(e => e.LastModified).IsRequired().IsConcurrencyToken(); 
Property(e => e.CreatedOn).IsRequired(); 
Property(e => e.CreatedOn2).IsRequired(); 
Property(e => e.CreatedOn3).IsRequired(); 
Property(e => e.CreatedOn4).IsRequired(); 
} 

Esto produce this, lo que significa que tendremos la excepción de desbordamiento.

Cambio de las asignaciones a esto mientras sigue trabajando con SQL CE 4.0:

Property(e => e.CreatedOn).IsRequired().HasColumnType("datetime2"); 
Property(e => e.CreatedOn2).IsRequired().HasColumnType("date"); 
Property(e => e.CreatedOn3).IsRequired().HasColumnType("date"); 
Property(e => e.CreatedOn4).IsRequired().HasColumnType("datetime2"); 

da esta error. Cambiar a SQL Server Standart 2012 parece resolver el problema (Esa no es una solución segura, solo para el experimento). El esquema de SQL Server creado es this.

No soy un experto en Sql pero me parece que SQL CE does not support these dates. el problema con el env del desarrollo permanece. DateTime puede ser sustituido pero puede traer mucha refactorización aquí y aquí.

Recuerde también que SqlDateTime and DateTime are very different.

La solución que me parece bueno - para el código y para el ciclo de vida del proyecto - es para cambiar entre LocalDB y standart SQL según lo sugerido por uno de los enlaces de arriba de stackoverflow combinada con la configuración de asignación fluentApi personalizada para igualar la creación del modelo o ambos .

Introduciendo custom convention in EF como una red de seguridad se ve bien también.

Si alguien tiene una mejor solución integral, tanto para el código como para la producción dev, publíquelo.