3

我有一个多层 SOA 应用程序和一个包含 100 多个表的数据库。我正在为我的数据层使用实体框架，它负责所有 CRUD 操作。

我有 1 个外观类，它托管在服务上，可由客户端应用程序调用。

这个外观类包含诸如

private void DoSomething()
{
  //insert to table1
  //insert to table 2
  //delete from table 3
  //more CRUD operations
}

并且外观类基本上充满了类似于 DoSomething() 的其他方法

所以客户端基本上会创建一个外观类的实例，并获得对所有这些方法的访问权限。

我现在的问题是，这是外观模式的最佳实践吗？我觉得外观类太“重”了，如果我的应用程序规模更大，我不确定它是否会影响性能。

如果我有很多方法，创建外观类的实例会是一项非常昂贵的操作吗？

4

2 回答 2

3

好吧，Facade 非常适合 SOA 架构，因为它将子系统封装为一个对象，并为您的客户提供所有业务对象和服务的聚合接口。它还减少了架构中的耦合。我认为您的方法并不繁重，并且不会影响系统的可扩展性。

于 2012-10-05T03:13:53.767 回答
0

如果我有很多方法，创建外观类的实例会是一项非常昂贵的操作吗？

假设在构造过程中没有调用这些方法，它们应该对对象的“重量”没有影响。我的理解是，一种不做任何事情的方法不会出于实际目的而消耗内存或周期。

（作为旁注，有一些技术限制不会为您的问题增加价值。请参阅C# 类可以有多少方法）

让你的门面为你工作！一个好的做法是假设您将它交给其他人并询问“这是否清楚地描述了我的 API 的功能是什么？”。60 听起来像是达到了我个人偏好的上限，但这仍然只是 15 个对象的 CRUD。

将外观视为一个统一的接口，可以让您腾出时间来创建更简洁和复杂的服务（反过来，它应该封装更简洁的存储库，而这些存储库又应该将更简洁的数据记录封装在表中，将 BLOBS 封装在存储桶中等） .

于 2012-10-06T21:08:28.903 回答