Entity Framework 和 SqlDateTime 溢出最佳实践答案

【问题标题】：Entity Framework and SqlDateTime overflow best practicesEntity Framework 和 SqlDateTime 溢出最佳实践
【发布时间】：2010-10-15 15:58:10
【问题描述】：

System.DateTime 可以采用比 SQL Server 的 DateTime 范围更广的值。因此有类System.Data.SqlTypes.SqlDateTime 模仿后者。

因此，我本来希望 Entity Framework 选择 SqlDateTime，但它没有。

所以我的问题是……

确保您的 DateTime 值在尝试将它们保存到数据库时不会导致问题的最佳做法是什么？

有没有办法强制 EF 使用 SqlDateTime？

【问题讨论】：

标签： entity-framework sqldatetime

【解决方案1】：

你可以做很多事情：

如果您使用的是 SQL Server 2008 或更高版本，则可以在数据库中使用DATE 或DATETIME2 数据类型，它们提供与.NET 的DateTime 相同的日期范围
/li>
如果您不能使用这些新数据类型，则在将内容存储到持久存储之前，您需要对日期字段进行一些检查/验证。 EF EntityObject 提供了许多方法来利用验证和保存对象的过程 - 选择一种适合您的方法

【讨论】：

【解决方案2】：

更具体地说，试试这个：http://www.vfstech.com/?p=111

【讨论】：

【解决方案3】：

也许这是一个旧线程，但我会将我的发现发布给其他人：

假设我们有开发环境：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; }
}

使用这样的自定义映射：

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();
}

这会产生this，这意味着我们会有溢出异常。

在仍然使用 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");

给这个error。切换到 SQL Server Standart 2012 似乎可以解决问题（这肯定不是解决方案 - 仅用于实验）。创建的 SQL Server 架构是 this。

我不是 Sql 专家，但在我看来 SQL CE does not support these dates。开发环境的问题。遗迹。 DateTime 可以被替换，但可以在这里和这里带来很多重构。

还要记住SqlDateTime and DateTime are very different。

我认为对代码和项目生命周期有益的解决方案是在 LocalDb 和 SQL 标准之间切换，如上面来自 stackoverflow 的链接之一的建议，结合自定义 fluentApi 映射设置以均衡模型创建或两者兼而有之。

引入custom convention in EF 作为安全网看起来也不错。

如果有人对代码和开发生产都有更好的全方位解决方案，请发布。

【讨论】：