随笔分类 -  Architecture

摘要：Singleton模式的实现基于两个要点： 1）不直接用类的构造函数，而另外提供一个Public的静态方法来构造类的实例。通常这个方法取名为Instance。Public保证了它的全局可见性，静态方法保证了不会创建出多余的实例。 2）将类的构造函数设为Private，即将构造函数"隐藏"起来，任何企图使用构造函数创建实例的方法都将报错。这样就阻止了开发人员绕过上面的Instance方法直接创建类的实例。 通过以上两点就可以完全控制类的创建：无论有多少地方需要用到这个类，它们访问的都是类的唯一生成的那个实例。以下C＃代码展现了两种实现Singleton模式的方式，开发人员可以 阅读全文

摘要：關於聚合/聚合根1. 如何界定聚合邊界？生命週期、一致性、高內聚2. 如何在EF中體現聚合與聚合根的概念？使用接口做泛型約束3. 只有聚合根才有倉儲，聚合成員如何CRUD？如果需要單獨CRUD則可能存在設計上的缺陷，作為整體聚合必須擁有一致性。 阅读全文

摘要：關於斷言的解惑：個人理解為斷言和無副作用函數都是用於解決邊界影響的方式。 在软件中，操作分为：命令和查询，命令就是能够使 系统状态发生改变的操作，如增删改等操作。这些操作都可能需要有副功能，如希望增删改完成后还要返回一些结果，这些主要功能之外的副业，也称为边界影响(side effect)。一些传统过程经验的程序员经常喜欢搞“一机多用”，喜欢将很多功能揉合在一起。 大多数操作会调用其他操作，造成任意深度的嵌套，这样形成一个树形结构的调用关系，这就容易使我们很难 预测调用一个操作会产生什么样的结果，调用一个操作变得谨慎，甚至战战兢兢，虽然Ioc或DI container使 得这种嵌套关系的管.. 阅读全文

摘要：今天有很多想法，雖然很多可能不成熟，也是學習的過程。在瞭解了工廠和倉儲後，對於工廠和倉儲之間的關係產生了一些問題。工廠僅作為新建和重建對象的地方，則可以將工廠和client隔離，這樣一來，需要新建和重建對象時，client需要通過倉儲向工廠發出請求，client無需關注他們如何工作，只是需要這個對象，就只會找倉儲要，倉儲讓工廠重裝。而另外一種是client直接向工廠發出請求，工廠新建和重裝對象，client拿到對象再通過倉儲進行存取。可是對於關係數據庫，數據庫存儲的比較類似于各個對象的“零件”，客戶需要對象時，問工廠要，工廠去取的零件組裝對象，組裝好了直接給客戶？這樣子并不是我所期望的，客戶爲 阅读全文

摘要：5.1 關聯指定一個導航方向 避免多對多。對於多對多並未提出解決方案，個人覺得建立關聯表是個方法。好吧這裡犯了數據庫驅動設計的毛病！加入限定符減少多重性 通過限定將一對多變成一對一，如時間上的限定，同一時間一個人只能有一張申請單，則時間限定就讓人和申請單變作一對一。清除不必要關聯 清除非關注的關聯，但如果需要擴展，我覺得有必要保留部份顯而易見的關聯。5.2 實體 標識必須唯一。5.3 值對象 個人認為，在設計時，應將公用值對象的實例持久化，如此做法可以提高性能，因為我們所關注的值對象，並不需要知道他是哪一個實例。具體做法可以研究（如全局變量、緩存技術）。當然，複製和共享所... 阅读全文

摘要：外部与一个子系统的通讯必须通过一个统一的门面（Facade）对象进行，这就是Facade模式。 现代的软件系统都是比较复杂的，设计模式的任务就是协助设计师处理复杂系统的设计。 设计师处理复杂系统的一个常见方法便是将其"分而治之"，把一个系统划分为几个较小的子系统。但是这样做了以后，设计师往往仍然会发现一个子系统内仍然 有太多的类型要处理。而使用一个子系统的使用端往往只关注一些特定的功能，却要同时与子系统内部的许多对象打交道后才能达到目的，请见下面的对象图。图4、Facade架构模式的结构图。 这就是一种不便，它使得系统的逻辑变得不必要的复杂，维护成本提高，复用率降低。 用一 阅读全文

摘要：贫血模型：是指领域对象里只有get和set方法，或者包含少量的CRUD方法，所有的业务逻辑都不包含在内而是放在Business Logic层。优点是系统的层次结构清楚，各层之间单向依赖，Client->(Business Facade)->Business Logic->Data Access(ADO.NET)。当然Business Logic是依赖Domain Object的。似乎现在流行的架构就是这样，当然层次还可以细分。该模型的缺点是不够面向对象，领域对象只是作为保存状态或者传递状态使用，所以就说只有数据没有行为的对象不是真正的对象。在Business Logic里面处 阅读全文