实体框架和SqlDateTime溢出最佳实践

发布于 2024-09-28 07:54:33 字数 260 浏览 1 评论 0原文

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

因此,我希望实体框架选择 SqlDateTime,但它没有。

所以我的问题是...

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

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

System.DateTime can take a wider range of values than SQL Server's DateTime. Hence there is class System.Data.SqlTypes.SqlDateTime which mimics the later.

Consequently I would have expected Entity Framework to choose SqlDateTime, but it didn't.

So my questions are...

What are the best practices to insure that your DateTime values will not cause problems when you try to save them to your database?

Is there any way of forcing EF to use SqlDateTime?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

非要怀念 2024-10-05 07:54:33

您可以执行多种操作:

  • 如果您使用的是 SQL Server 2008 或更高版本,则可以在数据库上使用 DATEDATETIME2 数据类型,提供与 .NET 的 DateTime

    相同的日期范围

  • 如果您不能使用这些新数据类型,则需要您来处理一些检查/验证在将内容存储到持久存储中之前,在日期字段上。 EF EntityObject 提供了多种方法来利用验证和保存对象的过程 - 选择一种适合您的方法

There's a number of things you can do:

  • if you're using SQL Server 2008 or newer, you can use the DATE or DATETIME2 data types on the database which offer the same date range as .NET's DateTime

  • if you can't use those new data types, it will be up to you to handle some checking / validation on your date fields before things are being stored into the persistent store. EF EntityObject offers lots of ways to tap into the process of validating and saving objects - pick one approach that works for you

逆光下的微笑 2024-10-05 07:54:33

更具体地说,请尝试以下操作:http://www.vfstech.com/?p=111

More specifically, try this: http://www.vfstech.com/?p=111

装迷糊 2024-10-05 07:54:33

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

假设我们有开发环境: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");

给出此错误
切换到 SQL Server Standart 2012 似乎可以解决问题(这不是一个确定的解决方案 - 仅用于实验)。创建的 SQL Server 架构是这个

我不是 Sql 专家,但在我看来 SQL CE 不支持这些日期。开发环境的问题。遗迹。 DateTime 可以被替换,但会带来大量的重构。

另请记住,SqlDateTime 和 DateTime 非常不同

我认为对于代码和项目生命周期来说很好的解决方案是在 LocalDb 和 SQL 标准之间切换,如上面 stackoverflow 中的链接之一所建议的那样,结合自定义 FluentApi 映射设置来均衡模型创建或两者。

在 EF 中引入自定义约定作为安全网看起来也不错。

如果有人有更好的全面解决方案,无论是代码还是开发生产,都可以发布。

Maybe this is an old thread but I will post my findings on this for the others :

Let say that we have dev env : 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; }
}

with such a custom mapping :

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 produces this, which means that we will have the overflow exception.

Changing the mappings to this while still working with 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");

Gives this error.
Switching to SQL Server Standart 2012 seems to solve the problem ( That is not a solution for sure - just for the experiment ). The created SQL Server schema is this.

I am not an expert in Sql but it looks like to me that SQL CE does not support these dates. the problem with development env. remains. DateTime can be substituted but can bring a lot of refactoring here and tehere.

Remember also that SqlDateTime and DateTime are very different.

The solution that I find good - for the code and for the project lifecycle - is to switch between LocalDb and SQL standart as suggested by one of the links above from stackoverflow combined with custom fluentApi mapping settings to equalize model creation or both.

Introducing custom convention in EF as a safety net looks good too.

If anybody has a better all-round solution, for code and for dev-production both, post it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文