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

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

 

 

(对比以下opensourceDotNetNuke 3.0.11 ,  .Text,  Duwamish7.0)

 

1 是否在一个postback过程中对connection只做一次openclose操作?

在一次业务周期中可以利用连接池,多次openclose连接.

但是在编写数据层的时候,一个类里最好只用一个连接,并且只打开一次。数据层的类应该实现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

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
评论

打赏作者

ruirui521

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值