網(wǎng)絡(luò)編程教程模板無憂>建站教程>網(wǎng)絡(luò)編程>.Net教程>

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

教程Tag：暫無Tag,歡迎添加,賺取U幣!

推薦：解讀鏈表的順序表示和實現(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上面看老趙寫的那幾篇文章(請看08年9月左右的文章)，感覺也很有深度，有不少啟發(fā)。因此我也打算寫一點我自己的實踐經(jīng)驗，希望也能同樣給大家一些有用的啟發(fā)吧。

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

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

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

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

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

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

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

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

這兩種形式如下所示：

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

// 通過實體對象來存儲
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è)計方式下面，
// 實際上根本沒有什么必要去傳輸整個對象。
// 我們可以想象，這個時候很多的操作其實是依賴UserId和CompanyId的，
// 而我見過的“有趣”設(shè)計，是在Page_Load事件中，不管是否需要用到，
// 都會將HttpContext.Current.User.Identity以及
// GetCompanyByUserId(userId).CompanyId保存為當(dāng)前頁面的全局變量。
// 其實這樣是違背了Linq的設(shè)計初衷的。
// 下面就是一個只傳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);
   }
}

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

如果是第二種情況，其實也不見得好到哪里去。因為：

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

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

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

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

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

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

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

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

以下為引用的內(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;
            }
        }
    }

然后我們再制作一個HttpModule（并且在web.config里面配置好）：

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

    /// <summary>
    /// 實現(xiàn)自動拋棄當(dāng)前數(shù)據(jù)庫上下文的模塊
    /// </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)限驗證
            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;
        }

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

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

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

ASP.NET視頻教程

北大青鳥ASP.NET編程視頻教程

ASP.NET一夜速成視頻教程

ASP.NET語音視頻教學(xué)

21天學(xué)通ASP.NET40小時多媒體語音視頻教學(xué)DVD

ASP.NET3.5從入門到精通視頻

.NET教學(xué)視頻免費下載

asp.net夜話教學(xué)視頻【完】

來源：模板無憂/所屬分類：.Net教程/更新時間：2009-07-10

[收藏][報錯][返回列表]

相關(guān).Net教程：

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

ASP.NET視頻教程

.Net教程Rss訂閱編程教程搜索

.Net教程推薦

猜你也喜歡看這些