这么多的数据访问选项，该使用什么？
我是一名 ASP.NET Web 应用程序开发人员，我一直使用带有存储过程的 Enterprise Library DAAB 来进行 4 个独立层（表示层、自定义类型层、业务逻辑层和数据访问层）的数据访问。
我的感觉是这种方法浪费了很多时间。
我没有使用过其他访问数据的方法，但肯定有很多方法可以节省开发时间。在搜索时，我读到了这些内容：
- 数据适配器，它们使用存储过程生成整个 DAL
- 具有不同flavers 的 Linq
- 实体框架
- 使用 SQLDataSource 和动态数据等数据控件
- 其他映射器、代码生成器和实用程序
如此多的选项和我的知识很少，我在制作时感到困惑考虑到我的开发可能是快速的、可扩展的、可重用的并且符合标准，我决定我应该采用什么开发模式。另外，我想找到一种方法，让我的代码库可以与其他技术（如 silverlight、mvc 框架、服务）一起使用（如果我需要使用的话）。
请指导我并帮助我。
谢谢
I am an asp.net web application developer and I always have used Enterprise Library DAAB with stored procedures for data access with 4 seprate layers (presentation layer, custom types layer, business logic layer and data access layer).
My feeling is that this approach is wasting much time.
I have not worked with other ways of accessing data but sure there are many ways that save development time. While searching I read about these:
- Data Adapters they generate whole DAL with stored procedures
- Linq with different flavers
- Entity Framework
- Using data controls like SQLDataSource and Dynamic Data
- Other mappers, code generaters and utilities
So much options and my little knowledge, I am confused in making decision what development patern I should adopt considering that my development may be fast, extendable, re-usable and up to the standard. Also I want to go for a way in which my code libraries can be used with other technolgies like silverlight, mvc framework, services if I ever need to use.
Kindly guide me and help.
thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于访问 SQL Server 等关系数据库，对象关系映射器 (ORM) 非常有用。在 .NET 领域，Microsoft 的实体框架和开源 NHibernate 是流行的选择。我强烈建议尝试其中之一。
实体框架在 Visual Studio 中具有拖放样式设计器支持，NHibernate 具有更好的基于代码的配置。我建议您尝试一下这些选项中哪一个对您来说最好。
通过企业库和存储过程，您很快就会发现这些工具使 CRUD 任务变得多么容易，但是与任何更复杂的更新和查询一样，还有一些东西需要学习。
For accessing relational databases such as SQL Server an Object Relational Mapper (ORM) is very useful. In the .NET space Entity Framework from Microsoft and the open source NHibernate are popular choices. I highly recommend trying one of these.
Entity Framework has drag-n-drop style designer support in Visual Studio and NHibernate has better code based configuration. I would recommend trying which ever of those options sounds best to you.
Coming from Enterprise Library and stored procedures you will quickly find how easy these tools make CRUD tasks, however like anything for more complex updating and querying there is a bit to learn.
你已经通过良好的实践做事了。你从事的任何事情只会让你所知道的事情变得更容易。混合、匹配、使用每个选项。没有什么会伤害你，因为你获得的知识只会让你更有价值。
You're already doing things with good practice. Anything that you move into will only make what you know go easier. Mix, match, use each option. Nothing will hurt you because the knowledge you gain will only make you more valuable.
有大量的模式需要阅读和研究（适配器、存储库、MVP 等）。您必须决定哪一个适合您。听起来您已经通过将业务逻辑与 UI 逻辑和数据访问层分离到一个单独的层来适当地对应用程序进行分层。编写软件很困难，但您可以更进一步，为您的类定义基本接口层，这样您就不必一遍又一遍地重写相同的接口，然后您可以通过添加到可用接口来进一步扩展该接口。这会节省你一些时间。
您还可以查看使用 MVC# 框架 或 MVC# 框架。 asp.net/mvc" rel="nofollow noreferrer">来自 Microsoft 的 ASP.NET MVC 框架。就您的存储库模式而言，您是否考虑过NHibernate？
祝你好运。
There are tons of patterns to read and study (Adapter, Repository, MVP, etc). You have to decide which one works for you. It sounds like you are already layering your applications appropriately by segregating your business logic from your UI logic and you data access layer into a separate layer. Writing software is hard but you could go a step further and define base interface layers for your classes so you don't have to rewrite the same interface over and over, then you can just extend that interface further by adding to the available interfaces. That would save you some time.
You can also look at using the MVC# framework or the ASP.NET MVC framework from Microsoft. As far as your repository pattern, have you considered NHibernate?
Good luck.