哪些因素会影响我在新项目中使用的数据访问层？
我将教授一门课程，我需要解释哪些因素会影响您对数据访问技术的决定。 我熟悉许多数据访问方法，例如类型化数据集、Linq to SQL、Linq to Entities、.netTiers、LLBLGen 以及使用 SQL 连接对象和命令对象的自定义调用。 我的一些客户只允许使用存储过程，他们不会讨论任何其他内容。 我的一些客户还没有准备好安装 .NET 3.5。 某些客户端在任何 Web 应用程序中都需要中间 Web 服务层。 大多数时候我使用类型数据集和自定义 Web 服务，或者将 .netTiers 与 CodeSmith 结合使用。 我还应该考虑什么？
I will be teaching a class sson, and I need to explain what factors should affect your decision of data access technology.
I am familiar with many data access methods like Typed Data Sets, Linq to SQL, Linq to Entities, .netTiers, LLBLGen, and custom calls with SQL connection objects and command objects.
Some of my clients will only allow stored procedures to be used, and they will NOT discuss anything else.
Some of my clients are NOT ready to install .NET 3.5 yet.
Some clients require a middle web service tier in any web application.
Most of the time I use Types Data Sets and Custom Web Services, or I use .netTiers with CodeSmith. What else should I be thinking about?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
要记住的一件重要的事情是，数据库不一定只是应用程序的后备数据存储（孤立的）。 其他应用程序和进程最终可能需要访问数据库，特别是在大型或“企业”数据库（或应用程序）中，并且特别是在有足够时间的情况下。
重要的是要考虑：
此外，一些设计考虑也是合理的。 您是否正在调整以加快选择速度或加快写入速度？ 一种数据访问设计可能比另一种表现更好。
我并不是说有一个灵丹妙药，但我要注意的是，任何数据访问设计模式都需要“大局”思考——它能否解决今天的问题以及您可以合理预测明天的需求吗？
另外，您会提供外部 API 或某些框架来实现一致的数据访问吗？ 会直接暴露还是间接暴露？
我认为实体框架/LINQ to SQL、传统存储过程和其他工具（如 NHibernate 等）都有一席之地，但您应该首先证明和合理化技术的选择，并尝试确保它适合于现在和未来的需求。
编辑：抱歉，我忘记了最重要的一点：可维护性。 一些模板驱动的解决方案为您提供了一些不错的优势，能够在架构更改后重新生成 DAL，优于其他解决方案（例如手写存储过程）。 值得权衡生产率的提高与劣势。
One important thing to remember is that a database is not necessarily just a backing data store for an application (in isolation). Other applications and process could eventually require access to the database, especially in large or “enterprise” databases (or applications) and especially given enough time.
It’s important to consider:
Also, some design consideration is in order. Are you tuning for faster selects, or faster writes? One data access design might perform better than another.
I’m not stating that there is a single silver bullet, but what I do caution is that any data access design pattern requires “big picture” thought - will it address today's concerns and what you can reasonably predict might be tomorrow's needs?
Also, will you be providing an external API or some framework for consistent data access? Will it be exposed directly or indirectly?
There’s a place, I think, for both the Entity Framework/LINQ to SQL, traditional Stored Procedures and other tools like NHibernate (etc), but you should justify and rationalise the choice of technology first, and try to ensure it is appropriate for the present and future needs.
EDIT: Sorry, I forgot the big one: maintainability. Some of the template driven solutions offer you some decent wins in being able to regenerate a DAL after schema changes, over others (like hand written stored procedures). It's worth weighing up the productivity gains vs the disadvantages.
就像软件项目中的所有选择一样：这取决于......
但我认为最重要的因素是项目的环境。
这包括（我并不认为这个列表是完整的）：
希望这对您有所帮助。
Like with all choice's in a software project : It depends...
But in my opinion the most important factor is the environment of the project.
This consists of (I don't claim that this list is complete in anyway):
hope this helps you.
我认为在您的原始帖子和norbertB 的补充之间，您已经涵盖了几乎所有内容。 从绝对约束开始（请记住，仅仅因为客户曾经对某件事说不 - 即使他们说这是绝对的 - 这并不意味着你无法帮助他们改变主意......）。 一旦你通过绝对限制缩小了范围，就可以看看其他事情。
似乎确实被遗漏的一件事是灵活性。 例如，如果我试图在两种相似的技术之间进行选择，并且我知道一种可以支持可更新视图，而另一种则不能，即使我当时完全不需要可更新视图，我仍然会倾向于那一种“万一”。
I think that between your original post and norbertB's additions you've covered just about everything. Start with the absolute constraints (and remember, that just because a client says no to something once - even if they say it's absolute - that doesn't mean you can't help change their mind...). Once you've narrowed down the field with the absolute constraints look at the other things.
One thing that did seem to be left out was flexibility. For example, if I were trying to choose between two similar technologies and I knew that one could support updateable views and the other couldn't, even if I had absolutely no need for updateable views at the time I would still lean towards that one "just in case".
我真的只想到两件事。 首先是我是否会拥有如此多的数据以至于其他任何事情都重要。 如果您没有将数百万行放入表中，那么您将使用哪种技术可能并不重要，因为它们的运行速度都足够快。
第二件事是我是否可以使用LINQ，因为我发现使用LINQ（到SQL、到Entities、到LLBLGen，这并不重要）来查询数据库可以给你带来两件重要的事情。 首先，编写查询非常容易；其次，在需求发生变化时，在需要 LINQ 的两个框架之间切换相当容易。
I'm really only thinking of two things. The first is whether I going to have so much data that anything else matters. If you're not putting millions of rows into the tables, it probably doesn't matter which technology you're going to use because they'll all work fast enough.
The second thing is whether I can use LINQ, because I find that using LINQ (to SQL, to Entities, to LLBLGen, it doesn't matter) to query the database gives you two important things. The first is that it's very easy to write queries and second, it's moderately easy to switch between two frameworks that need LINQ, in case requirements change.