开始构建数据访问层。需要考虑的事情？

我们的组织使用内联sql。我们一直负责提供合适的数据访问层，并权衡亲的利弊哪个方向走的......开始构建数据访问层。需要考虑的事情？

数据集
ADO.net
的LINQ
实体框架
亚音速
其他？我一直在使用参考

一些教程和文章：

我非常伤心，很难做出决定要走哪条路。我们的网站是一系列2个内部门户网站和一个公共网站。我们正在使用VS2008 SP1和框架版本3.5。

请你给我建议你需要考虑哪些因素，以及你在数据访问层遇到的任何专业和缺点。

PS。我发现这个亚音速网站的信息有点浅，而且很多重点似乎放在了如何“酷”它和开发者。我更喜欢对他们的演示视频的口头解释而不是音乐？其他人是否同意？

来源

2010-05-03 Phil

它看起来并不像你在“建造”，而是你正在寻找一个使用 - 或者你真的打算从头建立一个？（没有什么不对，我自己也是这样做的。） – 2010-05-03 13:01:06

我们对这个问题非常青睐，但是确实有开发资源和预算，并愿意编码/使用。我们想要避免的主要问题是首先跳入脚中，这样我们才能做到！（我已编辑的问题，以提供更清晰） – Phil 2010-05-03 13:05:03

请参阅：http://stackoverflow.com/questions/200279 http://stackoverflow.com/questions/66156 http://stackoverflow.com/questions/1055710 http：///stackoverflow.com/questions/2138814 http://stackoverflow.com/questions/168287 http://stackoverflow.com/questions/563775 http://stackoverflow.com/questions/67831 http://stackoverflow.com/问题/ 82393 http://stackoverflow.com/questions/1691575 http://stackoverflow.com/questions/380620 – 2010-05-03 13:08:53

数据集>对于您所得到的开销太多。这通常被认为是在它发布的那一天已经过去了。
ADO.Net（或企业图书馆）>我的个人偏好有很多原因。但是，我们从不使用内联SQL来解决其他一些原因（主要是安全问题），因此您的里程可能会有所不同。我们走这条路的一个原因是我们的团队对于SQL非常了解，并且每一个生成器在性能上都不尽人意，或者您必须知道大量的SQL来调整它们。有了这个选择，我们选择自己做。
Linq>跳过此。 LINQ的新发展已基本停止，MS的资源已转移到Entity Framework项目。我还发现了框架内的线程和其他问题尚未解决。
实体框架>有些人喜欢这样。您仍然需要大量的SQL知识才能充分利用它。
亚音速等>没有足够的经验与第三方的真正告诉你的利弊。

总结起来，我们更喜欢控制，并具备充分发挥它的知识。我们尝试了linq/EF路线，并没有给我留下深刻的印象。我见过其他人，并且与他们一起工作过，但是他们没有在除最基本的CRUD类型语句之外的任何东西上表演。

如果你正在做的大多数是CRUD相关的，那么EF，Subsonic或者类似的都可以。

它是怎样处理的即席查询：

有些事情评估时要考虑的？
它如何处理数据分页/排序（SQL方面还是将所有内容都拉入Web服务器）？
什么是内存泄漏？
线程是否需要？写一个简单的应用程序来测试你正在评估的每个应用程序。在不同的内存/ CPU条件下运行它。

祝你好运。

来源

2010-05-03 13:18:34 NotMe

不是一个简单的决定。我期待简单和灵活。例如，我不太喜欢配置NHibernate的xml文件;我不喜欢大量Entity Framework的代码。我担心linq-to-sql的生命结束。我不介意从基类派生（有些人希望纯粹的POCO对象）来支持映射。我也希望能够在不更改代码的情况下切换数据库，只需更改我的配置即可。其他小事情都很好，比如：能够将存储过程结果映射到对象;出于性能原因选择列的子集;如有必要，可以发送纯sql语句。

来源

2010-05-03 13:14:41

不需要在nhibernate上写xml映射:-) http://fluentnhibernate.org/ – 2010-05-03 13:20:18

流利的NHibernate显着降低了进入w/NHibernate的门槛。但它不是一个完整的集合。你可以使用FNH来完成大多数简单的映射，但是有些项目并未实现 - 例如映射存储过程是一个让人想起的巨大问题。 – bakasan 2010-05-04 06:12:27

如果您可以使用.NET 4.0，我会建议实体框架4。随着时间的推移，这是一个很好的ORM。你可以使用Linq编写你的查询，插入等，它给你一个与你今天使用的内联SQL相当接近的语法。显然，它背后有MS，所以你可以期待大量的信息和熟练的开发人员现在和未来都可以使用。

如果你必须留在.NET 3.5，我会看看NHibernate。它比EF4更成熟，但现在缺乏对Linq的全面支持。尽管您可以使用Linq进行相对简单的查询，但对于更复杂的查询，您将不得不使用类似SQL的标准API。我也会使用Fluent NHibernate来允许映射的代码内配置。它拥有强大的社区支持，并且在不久的将来应该有更好的Linq支持。它也有开源的优势。

这些ORM中的任何一个都会负责将系统中的对象映射到数据库。这将使您能够更专注于构建应用程序逻辑。出于这个原因，我不会建议使用ADO.Net/Datasets。 Linq2Sql非常适合它的功能，但永远不会像Nhibernate或EF4那么强大。 Linq2Sql总是看起来像是来自MS的第一次努力，似乎被降级为Entity Framework的第二把手。

来源

2010-05-03 13:15:48

现在所说的问题有点含糊。 “数据层”可以包含许多，许多，不同的需求和愿望。

我假设SQL Server是备份数据库。但它是唯一的吗？数据层的同质性如何？

你只是在寻找一种简单的方式来查询和获取数据？或者你是否需要一个全面的对象关系映射解决方案？除了查询之外，你有需求吗？例如迁移和脚手架？

你是否愿意或能够牺牲时间来提高学习更复杂（但灵活）的工具集，如NHibernate或亚音速？

工作过W /不同程度的复杂性与EF，LINQ到SQL，亚音速，和NHibernate，没有一个是“硬”的第一个走了，但寻找解决更复杂的问题或边缘的情况下将各自之间变化。人们可以争辩说，EF和NH拥有最多的用户，因此有点容易找到博客/ Stackoverflow帖子来回答你的问题。在这方面，我对EF/NH有更好的运气。也就是说，Subsonic是一个更易于使用的代码库，可以卷起袖子并修复自己的问题（IMO）。个人而言，在完成了几次运行之后，我现在的首选是始终开始工作，我认为这是最简单的解决方案 - Linq to SQL。我发现它的入门障碍是最低的，并且是最不“侵入”的。然而它带来了明显的限制（比如依赖于SQL服务器）。但是对于快速肮脏，只需完成工作，这是我的最爱，因为我宁愿不花费额外的时间来担心我的数据层。只有一次需求发生变化，我才会考虑离开 - 例如最近的一个项目需要读/写SQLite和SQL Server，因此我们去了NH。

了解您实际需要的内容可能有助于将答案从通用评论中排除。

来源

2010-05-04 06:20:25 bakasan

开始构建数据访问层。需要考虑的事情？

回答

相关问题