欧美日韩精品在线,国内精品久久久久久久久,一级毛片恃级毛片直播,清纯唯美亚洲综合欧美色

怎樣在ASP.NET項(xiàng)目里面正確使用Linq to Sql_.Net教程

編輯Tag賺U幣
教程Tag:暫無Tag,歡迎添加,賺取U幣!

推薦:解讀鏈表的順序表示和實(shí)現(xiàn)
/*List.h*/ #ifndef _LIST_H #define _LIST_H #define LIST_INIT_SIZE 100 #define LISTINCREMENT 10 template

Linq to Sql 用的人也應(yīng)該有些吧,我在cnblogs上面看老趙寫的那幾篇文章(請(qǐng)看08年9月左右的文章),感覺也很有深度,有不少啟發(fā)。因此我也打算寫一點(diǎn)我自己的實(shí)踐經(jīng)驗(yàn),希望也能同樣給大家一些有用的啟發(fā)吧。

我首先想要問一下大家,Linq to Sql有哪些很特別的地方?這個(gè)問題的答案肯定五花八門,我說一下我看到的一些問題吧。

首先,Linq to Sql的基礎(chǔ)之一是DataContext,而另外一個(gè)基礎(chǔ),則是通過映射產(chǎn)生的實(shí)體類,以及這些實(shí)體類的Table<>對(duì)象。這個(gè)不是廢話嘛!我想很多人都應(yīng)該知道這個(gè)最基本的知識(shí),不過卻不見得有多少人真正注意到,或者認(rèn)真思考一下這里面的“機(jī)關(guān)”。不知道“機(jī)關(guān)”在哪里,那么就不可能寫出合適的代碼。比如說,在某個(gè)頁面里面(N層結(jié)構(gòu)沒有給弄好的情況下),或者在某個(gè)業(yè)務(wù)邏輯里面(有N層結(jié)構(gòu)),你的Linq to Sql的代碼是否是長(zhǎng)這樣的?

以下為引用的內(nèi)容:

using (MyDataContext db = new MyDataContext)
{
  var q 
= from product in db.ProductInfos
          
where product.Price > 100
          select product;
  DoSomethingWithProducts(q.ToList());
}

“對(duì)啊,就是長(zhǎng)這樣的,有什么問題嗎?”當(dāng)然有問題啦,否則我也不寫這個(gè)隨筆了。不知道大家有沒有想過這么一個(gè)問題,什么叫做Context?Context就是上下文,上下文的意思就是,依賴于這個(gè)上下文的對(duì)象,必須存活在這個(gè)上下文里面。脫離了這個(gè)上下文,那些對(duì)象就會(huì)出現(xiàn)錯(cuò)誤。事實(shí)上也確實(shí)如此:在上面的例子里面,從ProductInfos中得到的q.ToList(),里面的每一個(gè)元素都依賴于MyDataContext。換句話說MyDataContext如果被注銷了,q.ToList()生成的對(duì)象也就會(huì)“部分功能失效”。

“失效就失效好了,反正該做的工作已經(jīng)做完了,q.ToList()也已經(jīng)利用完了。”不錯(cuò),在上面的例子里面,不會(huì)發(fā)生什么錯(cuò)誤。不過這么寫的話,會(huì)比較難使用的。為什么這么說?我舉一個(gè)具體的例子:這個(gè)網(wǎng)站需要用戶登錄,而所有的業(yè)務(wù)邏輯幾乎都依賴于當(dāng)前用戶。如果說,我們使用上面的using模式,那么我估計(jì)你的代碼不外乎是如下兩種情況:

1、每一次需要當(dāng)前用戶的地方,你都需要從數(shù)據(jù)庫(kù)讀取;或者

2、你把當(dāng)前用戶保存為全局變量了,但是你發(fā)現(xiàn)currentUser.CompanyInfo因?yàn)樯舷挛囊呀?jīng)拋棄了,因此是無法使用的,業(yè)務(wù)層不得不每一次都重新從數(shù)據(jù)庫(kù)讀取該用戶所屬公司的數(shù)據(jù)。

這兩種形式如下所示:

以下為引用的內(nèi)容:

// 通過實(shí)體對(duì)象來存儲(chǔ)
public double GetCurrentBalanceByObject()
{
   
int userId;
   
int.TryParse(HttpContext.Current.User.Identity, out userId);
   UserInfo user 
= GetUser(userId);
   CompanyInfo company 
= GetCompanyByUser(user);
   IQueryable
<TransactionInfo> transactions = GetTransactionsByCompany(company);
   
return transactions.Sum(item => item.Amount);
}

public UserInfo GetUser(int userId)
{
   
using(MyDataContext context = new MyDataContext)
   {
      
return context.UserInfos.Where(item => item.UserId == userId).FirstOrDefault();
   }
}

public CompanyInfo GetCompanyByUser(UserInfo user)
{
   
using(MyDataContext context = new MyDataContext)
   {
      
return context.CompanyInfos.Where(item => item.UserId == user.Id).FirstOrDefault();
   }
}

public IQueryable<Transaction> GetTransactionsByCompany(CompanyInfo company)
{
   
using(MyDataContext context = new MyDataContext)
   {
      
return context.TransactionInfos.Where(item => item.CompnayId == company.Id);
   }
}

// 實(shí)際上很容易就退化為通過鍵值來存儲(chǔ),因?yàn)樵谶@種設(shè)計(jì)方式下面,
// 實(shí)際上根本沒有什么必要去傳輸整個(gè)對(duì)象。
// 我們可以想象,這個(gè)時(shí)候很多的操作其實(shí)是依賴UserId和CompanyId的,
// 而我見過的“有趣”設(shè)計(jì),是在Page_Load事件中,不管是否需要用到,
// 都會(huì)將HttpContext.Current.User.Identity以及
// GetCompanyByUserId(userId).CompanyId保存為當(dāng)前頁面的全局變量。
// 其實(shí)這樣是違背了Linq的設(shè)計(jì)初衷的。
// 下面就是一個(gè)只傳Id的做法:
public double GetCurrentBalanceByObject()
{
   
int userId;
   
int.TryParse(HttpContext.Current.User.Identity, out userId);
   CompanyInfo company 
= GetCompanyByUserId(userId);
   IQueryable
<TransactionInfo> transactions = GetTransactionsByCompanyId(company.CompanyId);
   
return transactions.Sum(item => item.Amount);
}

public CompanyInfo GetCompanyByUser(int userId)
{
   
using(MyDataContext context = new MyDataContext)
   {
      
return context.CompanyInfos.Where(item => item.UserId == userId).FirstOrDefault();
   }
}

public IQueryable<Transaction> GetTransactionsByCompanyId(int companyId)
{
   
using(MyDataContext context = new MyDataContext)
   {
      
return context.TransactionInfos.Where(item => item.CompnayId == companyId);
   }
}

如果你是第一種情況,那么很明顯,你會(huì)有大量重復(fù)的SQL調(diào)用。

如果是第二種情況,其實(shí)也不見得好到哪里去。因?yàn)椋?/p>

1、currentUser可能不需要經(jīng)常取,但相關(guān)的其它內(nèi)容,由于上下文各自獨(dú)立,你還是經(jīng)常在重復(fù)的獲取的;

2、有一個(gè)地方你無法繞過去——如果你要修改當(dāng)前用戶的屬性,而這個(gè)全局的當(dāng)前用戶不是當(dāng)前Context產(chǎn)生的,你還非得從當(dāng)前Context取出來,然后再修改;

3、因?yàn)閏urrentUser的上下文已經(jīng)被拋棄了,因此程序會(huì)很容易設(shè)計(jì)成傳入的不是一個(gè)UserInfo,而是一個(gè)int類型的Id值,否則底層很容易一不小心就用到這個(gè)實(shí)際上功能不全的對(duì)象,然后就拋出異常了。但這樣做的后果是,獲取同一個(gè)類型的實(shí)體對(duì)象,可能會(huì)有各種不同的重載形式,例如:

以下為引用的內(nèi)容:

IQueryable<TransactionInfo> GetTransactionsByUserId(int userId);
IQueryable
<TransactionInfo> GetTransactionsByCompanyId(int companyId);

因?yàn)檫@種設(shè)計(jì)實(shí)施之后,有時(shí)很可能就會(huì)出現(xiàn)只有userId的情況,那么這個(gè)時(shí)候即使UserInfo對(duì)象中其實(shí)也存在CompanyId的值,也還是要重新獲取一遍UserInfo對(duì)象。為了簡(jiǎn)化這一過程,就可能會(huì)產(chǎn)生不同的獲取形式。

這樣設(shè)計(jì)完整個(gè)系統(tǒng)之后一跑,看著好像沒什么,但真正上線卻發(fā)現(xiàn)有點(diǎn)慢。當(dāng)我們打開Sql server的Profiler一看,會(huì)發(fā)現(xiàn)很簡(jiǎn)單的一個(gè)頁面的訪問,其數(shù)據(jù)庫(kù)訪問會(huì)搞到幾十次甚至上百次,其中有很多Sql語句是完全重復(fù)的。

這個(gè)問題怎么解決呢?有人會(huì)說,加個(gè)緩存機(jī)制吧。也許吧,但這種增加復(fù)雜度的設(shè)計(jì),我覺得還是不得已而為之的一種做法。我認(rèn)為更好的解決辦法是,將上下文在當(dāng)前頁面中緩存起來。所謂的上下文,就是一種運(yùn)行環(huán)境,而一次頁面訪問,其環(huán)境應(yīng)該是相同的。首先,我們對(duì)MyDataContext做一個(gè)擴(kuò)展:

以下為引用的內(nèi)容:

    partial class MyDataContext
    {
        
private const string c_KeyCurrentHttpContext = "chctx";

        
static public MyDataContext CurrentHttpContext
        {
            
get
            {
                MyDataContext context 
= CurrentHttpContextWeak;
                
if (context == null)
                {
                    context 
= new MyDataContext();
                    CurrentHttpContextWeak 
= context;
                }
                
return context;
            }
        }

        
static private MyDataContext CurrentHttpContextWeak
        {
            
get
            {
                
return HttpContext.Current.Items[c_KeyCurrentHttpContext] as MyDataContext;
            }
            
set
            {
                HttpContext.Current.Items[c_KeyCurrentHttpContext] 
= value;
            }
        }

        
static internal void TryDisposeCurrentHttpContext()
        {
            MyDataContext context 
= CurrentHttpContextWeak;
            
if (context != null)
            {
                context.Dispose();
                CurrentHttpContextWeak 
= null;
            }
        }
    }

然后我們?cè)僦谱饕粋(gè)HttpModule(并且在web.config里面配置好):

以下為引用的內(nèi)容:

    /// <summary>
    
/// 實(shí)現(xiàn)自動(dòng)拋棄當(dāng)前數(shù)據(jù)庫(kù)上下文的模塊
    
/// </summary>
    public class MyDataContextAutoDisposeModule : IHttpModule
    {
        
#region IHttpModule Members

        
private HttpApplication _context;
        
public void Init(HttpApplication context)
        {
            _context 
= context;
            context.PostRequestHandlerExecute 
+= new EventHandler(context_PostRequestHandlerExecute);
        }

        
void context_PostRequestHandlerExecute(object sender, EventArgs e)
        {
            MyDataContext.TryDisposeCurrentHttpContext();
        }

        
#endregion
    }

接下來,我們只要在邏輯層這么直接寫即可:

以下為引用的內(nèi)容:

        public static IQueryable<TransactionInfo> GetCompanyAccountDetails(UserInfo operatorUser, EAccountName account)
        {
            
// 權(quán)限驗(yàn)證
            if (!operatorUser.Permissions.Contains(EUserPermissions.ViewAccountDetails))
                CLog.CurrentHttpContext.ThrowFailedException(
new CPermissionException(EUserPermissions.ViewAccountDetails));

            var q 
= MyDataContext.CurrentHttpContext.TransactionInfos.Where(t => t.CompanyId == operatorUser.CompanyId && t.AccountName == account);
            
return q;
        }

這么改造完之后,你會(huì)發(fā)現(xiàn)幾乎可以在所有地方直接返回IQueryable(除了有的時(shí)候Linq to Sql本身有Bug),整個(gè)邏輯層內(nèi)的設(shè)計(jì)變得簡(jiǎn)單化:一開始檢查各種參數(shù)(是否具備完整或者部分權(quán)限),然后根據(jù)檢查結(jié)果做完全信賴的操作。由于返回的是實(shí)體對(duì)象,或者IQueryable,幾乎所有重復(fù)性的Sql調(diào)用也隨之自然消失了。如果有所懷疑的話,您可以用Sql Profiler自行做修改前后的對(duì)比,看看效果是否“驚人”?

也許有人會(huì)質(zhì)疑,這樣好嗎?豈不是通過user.Company.Transactions就可以得到所有的Transaction了?沒錯(cuò),如果所有東西都是公開的話,就會(huì)有這個(gè)問題。如果要徹底解決這樣的問題,需要將這些部分變成對(duì)邏輯層可見,而對(duì)其它層不可見的修飾方式——比如兩層在一個(gè)dll里面,這些屬性是internal的,或者放在兩個(gè)dll里面并且打上InternalsVisibleTo標(biāo)記。通過這種方式,就可以避免上層直接查找DAL中一些在BLL中需要經(jīng)過權(quán)限檢查才可以得到的內(nèi)容。當(dāng)然,如果項(xiàng)目比較小的情況下,你也可以選擇不要這么麻煩,直接控制代碼質(zhì)量即可(要求有些東西必須通過BLL來獲得)。

分享:淺談ASP.NET中顯示Linq To SQL輸出的SQL語句
最近在使用Linq To SQL的時(shí)候,為了了解不同Linq語句對(duì)性能造成的不同影響,需要獲得Linq To SQL生成的SQL語句。 如果是在桌面程序中,只需要 _context.Log = Console.Out; 即可在控制臺(tái)輸出SQL語句。可是在ASP.NET中又該怎么辦呢? 這時(shí)我想起了StringWriter

來源:模板無憂//所屬分類:.Net教程/更新時(shí)間:2009-07-10
相關(guān).Net教程