您的位置:首页 > 运维架构

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

2005-03-10 09:56 567 查看
如何组织性能最优,拓展型最好的业务层(一) 
 (对比以下opensource:DotNetNuke3.0.11,  .Text,  Duwamish7.0)

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

在一次业务周期中可以利用连接池,多次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--.Text。.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在.Text里运用singleton模式不是很明智。因为Singleton在处理大量并发请求调用的时候有效率问题?而且对业务方法来看,不应该使用Singleton模式的吧?但是又可以避免创建与销毁它的额外开销。这个地方希望有人来探讨一下。J
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息