如何组织性能最优，拓展型最好的业务层(一)

如何组织性能最优，拓展型最好的业务层(一)

 

 

(对比以下opensource：DotNetNuke 3.0.11 ,  .Text,  Duwamish7.0)

 

1 是否在一个postback过程中对connection只做一次open和close操作？

在一次业务周期中可以利用连接池，多次open和close连接.

但是在编写数据层的时候，一个类里最好只用一个连接，并且只打开一次。数据层的类应该实现IDisposable接口。

  在业务层中，一个业务方法对应一个数据层一个类的生命周期。例如：

public BookData GetCategoryItems(int categoryId)

{

    ApplicationAssert.CheckCondition(categoryId >= 0,"Invalid Category Id",ApplicationAssert.LineNumber);

using(Books bookDataAccess = new Books())

     {

       //you can do any other operation here.

       return bookDataAccess.GetBooksByCategoryId(categoryId);

     }

}

public BookData GetDailyPickItems(int categoryId)

{

    using (Books bookDataAccess = new Books())

    {

        return bookDataAccess.GetDailyPickBooksByCategoryId(categoryId);

    }

}

 

2 最大可拓展性， 将业务所有的操作都抽象出来，减少层与层之间的依赖性。

  业务层对象可以看作是一系列业务实现方法的集合，也可以从一些基类例如MarshalByRefObject等继承过来，来获得某些特殊性。将这些方法抽象出来，并不去实现它，而通过别的类对它的继承来实现。这样可以通过配置来决定使用哪种实现的方式。业务层的类不用实现IDisposable。（特殊情况除外）

  由于没有实现IDisposable，每次的释放工作交给了GC。如下例：

每次在需要调用业务方法的时候DataProvider. Instance()来获得一个业务层实例，而业务方法的实现并不需要被关心。

--------------------------抽象业务方法的类----------------------------------------

Public MustInherit Class DataProvider

  ' provider constants - eliminates need for Reflection later

  Private Const [ProviderType] As String = "data" ' maps to in web.config

Public Shared Function Instance() As DataProvider

  Dim strCacheKey As String = [ProviderType] & "provider"

  ' Use the cache because the reflection used later is expensive

   Dim objConstructor As ConstructorInfo = CType(DataCache.GetCache(strCacheKey), ConstructorInfo)

   If objConstructor Is Nothing Then

   ' Get the name of the provider

   Dim objProviderConfiguration As ProviderConfiguration = ProviderConfiguration.GetProviderConfiguration([ProviderType])

  ' The assembly should be in /bin or GAC, so we simply need to get an instance of the type

  Try

  ' Get the typename of the Core DataProvider from web.config

     Dim strTypeName As String = CType(objProviderConfiguration.Providers(objProviderConfiguration.DefaultProvider), Provider).Type

     ' Use reflection to store the constructor of the class that implements DataProvider

     Dim t As Type = Type.GetType(strTypeName, True)

     objConstructor = t.GetConstructor(System.Type.EmptyTypes)

     ' Insert the type into the cache

     DataCache.SetCache(strCacheKey, objConstructor)

     Catch e As Exception

     ' Could not load the provider - this is likely due to binary compatibility issues

  End Try

End If

Return CType(objConstructor.Invoke(Nothing), DataProvider)

End Function

‘ here is the abstract method

Public MustOverride Function GetProviderPath() As String

 

End Class

--------------------------实现DataProvider的类----------------------------------------

Public Class SqlDataProvider Inherits DataProvider

Private Const ProviderType As String = "data"

Private _providerConfiguration As ProviderConfiguration = ProviderConfiguration.GetProviderConfiguration(ProviderType)

    //constructor here

Public Sub New()

      ' Read the configuration specific information for this provider

        Dim objProvider As Provider = CType(_providerConfiguration.Providers(_providerConfiguration.DefaultProvider), Provider)

      ' Read the attributes for this provider

End Sub

//implement the abstract method in DataProvider

Public Overrides Function GetProviderPath() As String

End Function

End Class

 

通常使用这样的方法，从设计模式上来看，是strategy module吧，又有点类似MVC里面的调用方式（虽然这并不是观测者模式）。反正这样很大的降低了层与层之间的偶合性。有些人看到了Instance()方法，会说，这是不是个singleton模式呢？不是，因为仔细分析，会发现每次调用Instance()实际都创建了一个新的instance。

 

然后我们再来看看我们现在使用的blog－－. Tex t。

.Text实现的方法和我上面提到的很相似，但是他在处理业务层的时候有点细微的差别。

.Text仍然将业务方法抽象了出来，一样的使用可配置选择调用那个类来实现这些抽象的方法。但是，让我们来看看下面的一段代码：

public class DbProvider

{

     private DbProvider()

     {}

static DbProvider()

     {

         DbProviderConfiguration dpc = Config.Settings.BlogProviders.DbProvider;

         dp = (IDbProvider)dpc.Instance(); //从配置中读出的配置节点类创建一个实例。

         dp.ConnectionString = dpc.ConnectionString;

     }

     private static readonly IDbProvider dp = null;

     public static IDbProvider Instance()

     {

         return dp;

     }

}

这个DbProvider要结合IDbProvider看。抽象的方法都在IDbProvider中，DbProvider其实只是提供了一个调用的入口。我们分析DbProvider类，可以发现他创建实例的过程放到了DbProvider的静态构造函数中，而将自己的构造函数private掉了，这其实是一个非常典型singleton的模式。这意味着在它被创建了一次就一直存在直道application结束。以后每次通过Instance()方法获得实例其实都是在内存中的静态实例而不会反复创建。

而我前面用Vb.Net实现的方法是每次都创建了一个实例，然后交给GC回收。

目前这两个方式孰优孰逆？本人个人意见是Scott在. Tex t里运用singleton模式不是很明智。因为Singleton在处理大量并发请求调用的时候有效率问题？而且对业务方法来看，不应该使用Singleton模式的吧？但是又可以避免创建与销毁它的额外开销。这个地方希望有人来探讨一下。J