使用存儲過程時,哪個ORM是最好的

[英]Which ORM is the best when using Stored Procedures


I have Business objects (DEVELOPERS WRITE) and some SPROCS (DBA WRITE)

我有業務對象(開發人員編寫)和一些SPROCS (DBA編寫)

Can anyone recommend a good object mapper to deal with this kind of setup.

有人能推薦一個好的對象映射器來處理這種設置嗎?

I tried codesmith and nhibernate and had trouble. I do not mind if my ORM is free or paid.

我嘗試了codesmith和nhibernate,但遇到了麻煩。我不介意我的ORM是免費的還是付費的。

8 个解决方案

#1


7  

SubSonic has excellent support for sprocs. It will wrap each one in a helper method and you can retrieve strongly-typed collections or entities from the results if you want. I show a way to do that in this blog post. As long as your sproc returns the same schema as SELECT * FROM TableName would, it will work with your SubSonic entities.

亞音速對sprocs有很好的支持。它將把每一個都封裝在一個helper方法中,如果您願意,您可以從結果中檢索強類型的集合或實體。我在這篇博客文章中展示了一種方法。只要您的sproc返回與SELECT *相同的模式,它將與您的亞音速實體一起工作。

As far as generating classes based on your db, SubSonic generates partial classes so you can extend them as needed. You could also do mappings from the SubSonic generated classes to your actual model.

就基於db生成類而言,亞音速生成部分類,因此您可以根據需要擴展它們。您還可以做從亞音速生成的類到實際模型的映射。

#2


5  

Subsonic has a flexible solution:

亞音速有一個靈活的解決方案:

    class CustomerOrder {
        private string productName;

        public string ProductName {
            get { return productName; }
            set { productName = value; }
        }
        private int total;

        public int Total {
            get { return total; }
            set { total = value; }
        }

    }

Then:

然后:

List<CustomerOrder> orders = Northwind.SPs.CustOrderHist("ALFKI")
        .ExecuteTypedList<CustomerOrder>();

Subsonic is a solid "Swiss Army knife" style ORM.

亞音速是一種堅固的“瑞士軍刀”風格。

#3


5  

Disclaimer: I am the author of Dapper.

免責聲明:我是《衣冠楚楚》的作者。


If you are looking for a simple object mapper that handles mapping procs to business objects Dapper is a good fit.

如果您正在尋找一個處理將procs映射到業務對象的簡單對象映射程序,那么Dapper是一個很好的選擇。

Keep in mind it ships with no "graph management", "identity map" and so on. It offers a bare bone, complete solution which covers many scenarios other ORMs do not.

記住,它沒有“圖形管理”、“標識映射”等等。它提供了一個裸骨,完整的解決方案,涵蓋了許多其他orm沒有的場景。

Nonetheless, it offers one of the fastest object materializers out there, which can be 10x faster than EF or even 100x faster than subsonic in some benchmarks.

盡管如此,它還是提供了一種最快的物質體,比EF快10倍甚至比亞音速快100倍。


The trivial:

微不足道的:

create proc spGetOrder
   @Id int
as 
select * from Orders where Id = @Id
select * from OrderItems where OrderId = @Id 

Can be mapped with the following:

可繪制如下圖:

var grid = cnn.QueryMultiple("spGetOrder", new {Id = 1}, commandType: CommandType.StoredProcedure);
var order = grid.Read<Order>();
order.Items = grid.Read<OrderItems>(); 

Additionally you have support for:

此外,您還支持:

  1. A multi-mapper that allows you single rows to multiple objects
  2. 一個多映射器,允許單個行到多個對象。
  3. Input/Output/Return param support
  4. 輸入/輸出/返回參數的支持
  5. An extensible interface for db specific parameter handling (like TVPs)
  6. 用於db特定參數處理的可擴展接口(如TVPs)

So for example:

舉個例子:

create proc spGetOrderFancy
   @Id int,
   @Message nvarchar(100) output 
as 
set @Message = N'My message' 
select * from Orders join Users u on OwnerId = u.Id where Id = @Id
select * from OrderItems where OrderId = @Id
return @@rowcount

Can be mapped with:

可以映射:

var p = new DynamicParameters(); 
p.Add("Id", 1);
p.Add("Message",direction: ParameterDirection.Output);
p.Add("rval",direction: ParameterDirection.ReturnValue);
var grid = cnn.QueryMultiple("spGetOrder", p, commandType: CommandType.StoredProcedure);
var order = grid.Read<Order,User,Order>((o,u) => {o.Owner = u; return o;});
order.Items = grid.Read<OrderItems>(); 

var returnVal = p.Get<int>("rval"); 
var message = p.Get<string>("message"); 

Finally, dapper also allow for a custom parameter implementation:

最后,dapper還允許定制參數實現:

public interface IDynamicParameters
{
   void AddParameters(IDbCommand command);
}

When implementing this interface you can tell dapper what parameters you wish to add to your command. This allow you to support Table-Valued-Params and other DB specific features.

在實現這個接口時,您可以告訴dapper您希望添加到您的命令中的哪些參數。這允許您支持表值解析器和其他DB特定特性。

#4


2  

Depending on the database Entity Framework, or NHibernate are likely your best options (examples in links).

根據數據庫實體框架,或者NHibernate可能是您最好的選擇(鏈接中的示例)。

#5


1  

The LINQ to SQL designer will give you type-safe sprocs as methods on the DataContext object. You can map those to objects for CRUD operations fairly easily.

LINQ to SQL designer將為您提供類型安全的sprocs作為DataContext對象的方法。您可以很容易地將它們映射到CRUD操作的對象。

In fact, I'm in the middle of doing exactly that.

事實上,我正在做這個。

#6


1  

Since you've got a DBA writing the sprocs, I would think the best thing to do would be to work closely with him to figure out how to map the tables to objects, and how to structure the database so that it works with your domain model. There's nothing wrong with sprocs, they just require close collaboration between the developers and the DBAs.

既然有一個DBA在編寫sprocs,我認為最好的做法是與他密切合作,找出如何將表映射到對象,以及如何構造數據庫,使其與域模型協同工作。sprocs沒有問題,它們只需要開發人員和dba之間的密切協作。

Ideally, the DBA in question is part of your project team...

理想情況下,所討論的DBA是項目團隊的一部分……

#7


0  

I like the way the Entity Framework handles sprocs right now. You can associate sprocs with the crud operations of an entity, it even detects which sprocs match up with the properties of your entity. The one big downside right now is if you associate one sproc with an entity you must associate all the crud operations with a sproc.

我喜歡實體框架現在處理sproc的方式。您可以將sprocs與實體的crud操作相關聯,它甚至可以檢測哪些sprocs與實體的屬性相匹配。現在的一個大缺點是,如果您將一個sproc與一個實體相關聯,那么您必須將所有crud操作與一個sproc相關聯。

This EF Sproc article has some great examples of how to use sprocs in EF and has some really nice Extension methods for it as well.

這篇EF Sproc文章有一些關於如何在EF中使用Sproc的很好的例子,並且有一些很好的擴展方法。

#8


0  

The main issue I see with this, is that by going with SP you are automatically loosing lot of the flexibility you get when using ORM, specially on the retrieval of information. Because of this, I am sure you won't be able to use All of the features of most ORM.

我看到的主要問題是,通過使用SP,你會自動失去使用ORM時的靈活性,特別是在信息檢索方面。正因為如此,我確信您將無法使用大多數ORM的所有特性。

For example, if you use linq2sql, you will have pretty much wrapper to the SPs. You can also map insert, deletes and updates of the generated entities to stored procedures. Where you loose a lot is on the retrieval of information, both because the queries are now fixed (and you might retrieve more information than needed i.e. extra columns - or create lots of SPs) and on lazy loading.

例如,如果您使用linq2sql,那么您將擁有很多jsp的包裝器。還可以將生成的實體的插入、刪除和更新映射到存儲過程。在檢索信息時,您會丟失很多信息,這是因為查詢現在是固定的(而且您可能會檢索到比需要的更多的信息,例如額外的列——或者創建大量的SPs),以及延遲加載。

Update: I am more a linq2sql guy, but I would take a second look at the assumptions you are taking about NHibernate. In particular, I doubt it will force column order as it is configured with column names (see http://nhibernate.info/blog/2008/11/23/populating-entities-from-stored-procedures-with-nhibernate.html). It also supports something I don't know how to do with linq2sql: http://nhibernate.info/blog/2008/11/23/populating-entities-with-associations-from-stored-procedures-with-nhibernate.html. Note, I don't mean that last one isn't supported with linq2sql, just that I don't know how to ;)

更新:我更喜歡linq2sql,但是我想再看看您對NHibernate的假設。特別是,我懷疑它會強制列順序,因為它配置了列名(參見http://nhibernate.info/blog/2008/11/23/populatentis-from-storing-procedure - hibernate -nhibernate.html)。它還支持一些我不知道如何使用linq2sql的東西:http://nhibernate.info/blog/2008/11/23/populating-entiation -with- associated -from-stored-procedure -with-nhibernate.html。注意,我並不是說最后一個不支持linq2sql,只是我不知道如何;)


注意!

本站翻译的文章,版权归属于本站,未经许可禁止转摘,转摘请注明本文地址:https://www.itdaan.com/blog/2009/03/26/72a20bf64faab1242e0fa8d388a2aa72.html



 
粤ICP备14056181号  © 2014-2020 ITdaan.com