创建一个松散耦合/可扩展的软件架构

问题描述

我一直在研究几个星期。我目前正在使用n层（3层）方法和工厂设计方法设计一个松散耦合的架构设计。我的目标是将每个客户的业务逻辑（ClientA.DLL，ClientB.DLL）放在单独的命名空间中，以便项目扩展意义我可以修改/删除/添加特定客户端业务逻辑，而不影响其他客户端，因为它不依赖于每个其他。然后我通过Factory命名空间使用客户端的唯一标识符（数据库中维护的字符串值）调用客户端的命名空间/类。 Factory.DLL 还隐藏每个客户端的逻辑。而 BusinessAbstract.DLL 作为每个客户端的类将使用的布局或模板。

I been researching for weeks about this.. I'm currently designing a loosely-coupled architecture design using n-tier(3 layered) method and factory design approach. My goal is to put each Client's business logic (ClientA.DLL, ClientB.DLL) in separate namespaces so that the project scales out meaning I can modify/remove/add a specific clients business logic without affecting the others because its not dependent to each other. Then I Invoke the client's namespaces/class using the client's unique identifier (a string value that is maintained in the database) via the Factory namespace. The Factory.DLL also hides the per-client logic. While the BusinessAbstract.DLL serve as the Layout or the Template that the per-client's classes will be using.

这是项目解决方案。

这里是实际代码：

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";
    }
   }
 }

AbstractBusinessRule的ClientA实现

ClientA implementation of the 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);
      }
  }

演示文稿层

网站

 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

 }

有关此设计的任何意见/建议。我需要你的输入，我如何改善这个结构。感谢提前。

Any comments/suggestion about this design. I need your input guys on how I can improve this structure. Thanks in advance.

推荐答案

我唯一看到的是，我只是在看着你的帖子中错过了，但是我没有看到一个DAL接口定义或抽象层，它以BL的方式将其从BL中分离出来。

The only thing I see, and I mist just be missing this in looking at your post, but I don't see a DAL interface definition or abstraction layer that seperates it from your BL in the way your BL is abstracted from your presentation.

这很重要，因为它给了你未来可以灵活地创建使用相同数据的新业务层，而无需重写DAL，或者在单元测试/第三方维护的SOAP Web服务响应中替换数据库，或使用平面CSV文件/将来更好的数据存储机制。

This is important because it gives you the flexibility in the future to create a new business layer using the same data without having to rewrite the DAL, or replacing your database with flat CSV files/mocks in unit testing/a 3rd party maintained soap web service response, or whatever else might be a better data storage mechanism in the future.

这篇关于创建一个松散耦合/可扩展的软件架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！