ORM 适合我的目的吗
我们通常在数据库上编写存储过程，它接受 xml 并以 xml 形式返回结果集。我正在考虑为数据库调用提供一个抽象，如下
例
public List<Person> GetAllPeople()
{
string requestXml = "<Request><Type>GetAllPeople</Type></Request>";
//execute a procedure with above xml as input
//load the response xml into dataset
//foreach record instantiate Person & add to list
return List<Person>();
}
所示，以便团队可以使用强类型对象而不是松散耦合的 Xml 字符串。我想这就是ORM所做的工作吧？或者我应该编写自己的数据访问层来返回对象而不是数据集和数据表。所以问题是
ORM适合这种类型的数据访问吗？
抽象数据库调用的正确路径是什么？
规格
SQL Server 2005、.NET 2.0、ASP.NET 2.0、C# 2.0
We usually write stored procedures on the database which accepts xml and returns result set as xml. I am thinking of providing a abstraction for the database calls like below
Example
public List<Person> GetAllPeople()
{
string requestXml = "<Request><Type>GetAllPeople</Type></Request>";
//execute a procedure with above xml as input
//load the response xml into dataset
//foreach record instantiate Person & add to list
return List<Person>();
}
so that the team can work with strongly typed objects rather loosly coupled Xml Strings. I think this is the work that ORM does right? Or should i code my own Data access layer to return objects rather than dataset and datatables. So the question is
Will ORM suit this type of data access?
What would right path to follow for abstracting database calls?
Specs
SQL Server 2005, .NET 2.0, ASP.NET 2.0, C# 2.0
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一定要设计一个数据访问层。该层将由 DAO 类组成，每个类用于访问特定类型的数据（或对象，如果它是 OO 系统）。
现在由您决定如何编写该层。你有多种选择：
如果您决定使用 ORM，请确定您要进入的领域。构建几个演示项目来了解 ORM 的工作原理。
现在，我对存储过程有点怀疑，主要是因为它可以做各种各样的事情——数据检索和逻辑执行。我避免使用存储过程以确保所有业务逻辑都在我的代码中（无论是 java、PHP 还是其他）。对于相对较小的系统，我建议您使用基于简单 SQL 查询的数据访问层。
Definitely devise a data access layer. This layer will be comprised of DAO classes, each class for accessing specific types of data (or objects, if its an OO system).
Now its up to you how you want to write this layer. You have several choices:
If you decide you want to go with ORMs, make sure what you're getting into. Build a couple of demo projects to understand how the ORM works.
Now, I'm a little skeptical about stored procedures, mainly because can do all kinds of stuff - both data retrieval, and logic execution. I avoid stored procs to make sure that all business logic is in my code (be tha tjava, PHP or other). For relatively small systems, I advise you to go with a simple SQL query based Data Access Layer.