我有一个多层SOA应用程序和一个包含100多个表的数据库。我正在为我的数据层使用实体框架来处理所有CRUD操作。
我有1个门面类，它托管在服务上，可以通过客户端应用程序全部调用。
此Facade类包含
等方法private void DoSomething()
{
//insert to table1
//insert to table 2
//delete from table 3
//more CRUD operations
}
Facade类基本上已经满载了许多其他方法，类似于DoSomething（）
因此，客户端基本上将创建一个facade类的实例，并获得对所有这些方法的访问权。
我现在的问题是，这是门面图案的最佳做法吗？我觉得门面类太“重”了，如果我的应用程序扩展得更大，我不确定它是否会影响性能。
如果我有大量的方法，那么创建一个外观类的实例会是一个非常昂贵的操作吗？
答案 0 :(得分：3)
嗯，一旦将子系统封装为一个对象并为您的客户端提供所有业务对象和服务的聚合接口，Facade就非常适合SOA架构。它还减少了架构中的耦合。我认为您的方法并不重，不会影响系统的可扩展性。
答案 1 :(得分：0)
创建Facade类的实例会非常昂贵 操作，如果我有大量的方法吗？
假设在构造过程中没有调用这些方法，它们应该对对象的“权重”没有影响。我的理解是，一种没有做任何事情的方法不会为了实际目的而花费内存或周期。
（作为旁注，有些技术限制不会为您的问题增加价值。请参阅How many methods can a C# class have）
让你的外观适合你！一个好的做法是假设你把它交给别人并问“这样可以巧妙地描述我的API的功能是什么吗？”。六十个听起来像是达到了我个人偏好的上限，但这仍然只是15个对象的CRUD。
将外观视为一个统一的界面，让您自由地创建更简洁和复杂的服务（反过来应该封装更简洁的存储库，而这些存储库又应该在表中封装更简洁的数据记录，BLOBS在存储桶中，等）。