创建松散耦合/可扩展的软件架构
我已经研究了好几个星期了。 我目前正在使用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(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("ClientA"); Response.Write(obj.GetClientBLL()); //prints clientA method obj = Invoker.GetMemberInstance("ClientB"); Response.Write(obj.GetClientBLL()); //prints clientB method }
而且你还会注意到我在每个客户端DLL和AbstractBusinessRule DLL中都有一个DAL文件夹，因为我还想缩放DAL层并使用层结构“UI-BLL-DAL”。
欢迎任何有关此设计的意见/建议。 我希望能得到关于如何改进这种结构的意见。 提前致谢。
我看到的唯一的东西，我只是在看你的post时错过了这个，但是我没有看到一个DAL接口定义或抽象层，它将你的BL从你的演示文稿中抽象出来的方式与你的BL分开。
这很重要，因为它使您可以灵活地使用相同的数据创建新的业务层，而无需重写DAL，或者在unit testing/第三方维护的soap Web服务中使用平面CSV文件/模拟替换您的数据库响应，或其他任何可能是未来更好的数据存储机制。
您基本违反了关注点分离/单一责任原则：您的业务对象了解其存储。
3层体系结构的数据层应该负责CRUD操作，并且应该查询消费者需要的对象的实例。 像这样的东西：
Presentation Layer ------- Data Layer || || Business Layer
这允许业务层专注于实现，并保持持久性问题。 如果表示层需要一个新的业务对象（用于创建），它会向数据层询问它。
我的第一个评论是你的名字需要更具描述性。 通过查看解决方案大纲，您的程序实际上做了什么并不明显。 如果您为客户端类和工作区提供有意义的名称，那么这将是朝着正确方向迈出的一步。
这个问题太过广泛，没有一个最好的方法。
个人基础上添加类和inheritance的扩展点没有真正的案例，从而强烈受益于它，我已经看到了各种各样的复杂性。
很难说明所提供的信息量，但考虑使用更基于配置的方法的替代方法/并不意味着配置文件，只是传递到系统中的配置。
您可以拥有一组基本规则，以及将一组规则应用于客户端的默认配置。 如果您在代码中执行此操作，则在添加客户端配置时，您可以只说.AddClient（“ClientA”），它将仅使用默认规则。
或者，您可以在添加客户端时指定适用于客户端进程的规则，这可能涉及为这些规则设置不同的规则甚至不同的配置值。
ClientA可能需要不包含在基本规则中，然后可以将自定义/代码业务规则应用于客户端进程。
我不会尝试跳转到这样的通用框架。 相反，我会将上述内容集中在具体流程上，并为这些流程公开扩展点。 当你在解决方案中工作时，应该出现常见的模式，然后在适当的时候（看到真正的好处）你可以将它重构为更通用的东西。