創建松散耦合/可擴展的軟件架構

Question

我已經研究了好幾個星期了。 我目前正在使用n層（3層）方法和工廠設計方法設計松散耦合的架構設計。 我的目標是將每個客戶端的業務邏輯（ClientA.DLL，ClientB.DLL）放在單獨的命名空間中，以便項目擴展，這意味着我可以修改/刪除/添加特定客戶端的業務邏輯而不會影響其他客戶端，因為它們是不依賴於彼此。 然后，我使用客戶端的唯一標識符（在數據庫中維護的字符串值）通過Factory命名空間調用客戶端的名稱空間/類。 Factory.DLL還隱藏了每個客戶端的邏輯，而BusinessAbstract.DLL則用作每個客戶端的類將使用的布局或模板。

這是項目解決方案：

這是實際的代碼：

BusinessAbstract.DLL

namespace BusinessAbstract
{
   // the entity / data transfer object
   public class MemberDTO
   {
      public string MemberID { get; set; }
      public string MemberName { get; set; }
    }

   // the interface
   public interface IMaintainable
   {
      void Add();
      void Edit();
      void Delete();
   }

  // the base abstract class, implements the Entity and the Interface
  public abstract class Member : MemberDTO, IMaintainable
  {
    // Implement IMaintanable but change it to abstract
    public abstract void Add();
    public abstract void Edit();
    public abstract void Delete();

    // a method with Database access, get from DAL
    public virtual MemberDTO GetMemberDetails(params object[] args)
    {
        return DAL.MemberDAL.FetchMemberDetails(args);
    }

    public virtual string GetClientBLL()
    {
        return "base's method";
    }
   }
 }

ClientA實現了AbstractBusinessRule

ClientA.DLL

 namespace ClientA
 {
    public class _Member : BusinessAbstract.Member
   {
       public override void Add()
      {
        throw new NotImplementedException();
      }

      public override void Edit()
      {
        throw new NotImplementedException();
      }

      public override void Delete()
      {
        throw new NotImplementedException();
      }

      public override string GetClientBLL()
      {
        return "ClientA Method";
      }
    }
 }

該工廠

Factory.DLL

 public static class Invoker
 { 
     public static T GetMemberInstance<T>(string clientCode)
        where T : Member, IMaintainable
      {
        Type objType = Type.GetType(clientCode + "._Member," + clientCode);
        return (T)Activator.CreateInstance(objType);
      } 
  }

Presentation Tier上的示例實現

網站

 protected void Page_Load(object sender, EventArgs e)
 {

    // invoke Member class using String hardcode
    Member obj = Invoker.GetMemberInstance<Member>("ClientA");
    Response.Write(obj.GetClientBLL()); //prints clientA method

    obj = Invoker.GetMemberInstance<Member>("ClientB");
    Response.Write(obj.GetClientBLL()); //prints clientB method

 }

而且你還會注意到我在每個客戶端DLL以及AbstractBusinessRule DLL中都有一個DAL文件夾，因為我還想縮放DAL層並使用層結構“UI-BLL-DAL”。

歡迎任何有關此設計的意見/建議。 我希望能得到關於如何改進這種結構的意見。 提前致謝。

Answer 1

我看到的唯一的東西，我只是在看你的帖子時錯過了這個，但是我沒有看到一個DAL接口定義或抽象層，它將BL從你的演示文稿中抽象出來的方式與你的BL分開。

這很重要，因為它為您提供了使用相同數據創建新業務層的靈活性，而無需重寫DAL，或者在單元測試/第三方維護的soap Web服務中使用平面CSV文件/模擬替換數據庫響應，或其他任何可能是未來更好的數據存儲機制。

Answer 2

您基本違反了關注點分離/單一責任原則：您的業務對象了解其存儲。

3層體系結構的數據層應該負責CRUD操作，並且應該查詢消費者需要的對象的實例。 像這樣的東西：

Presentation Layer ------- Data Layer
                              ||
                              ||
                       Business Layer

這允許業務層專注於實現，並保持持久性問題。 如果表示層需要一個新的業務對象（用於創建），它會向數據層詢問它。

Answer 3

我的第一個評論是你的名字需要更具描述性。 通過查看解決方案大綱，您的程序實際上做了什么並不明顯。 如果您為客戶端類和工作區提供有意義的名稱，那么這將是朝着正確方向邁出的一步。

Answer 4

這個問題太過廣泛，沒有一個最好的方法。

個人基礎上添加類和繼承的擴展點沒有真正的案例，從而強烈受益於它，我已經看到了各種各樣的復雜性。

很難說明所提供的信息量，但考慮使用更基於配置的方法的替代方法/並不意味着配置文件，只是傳遞到系統中的配置。

您可以擁有一組基本規則，以及將一組規則應用於客戶端的默認配置。 如果您在代碼中執行此操作，則在添加客戶端配置時，您可以只說.AddClient（“ClientA”），它將僅使用默認規則。

或者，您可以在添加客戶端時指定適用於客戶端進程的規則，這可能涉及為這些規則設置不同的規則甚至不同的配置值。

ClientA可能需要未包含在基本規則中，然后可以將自定義/代碼業務規則應用於客戶端進程。

我不會試圖一直跳到這樣一個通用的框架。 相反，我會將上述內容集中在特定流程上，並為這些流程公開擴展點。 當你在解決方案中工作時，應該出現常見的模式，然后在適當的時候（看到真正的好處）你可以將它重構為更通用的東西。