Best practice for application facade pattern

Question

I have a multi tiered SOA application and a database with over 100 tables. I'm using entity framework for my data layer which takes care of all CRUD operations.

I have 1 facade class which is hosted on a service, callable by client apps all over.

This facade class contains methods such as

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

And the facade class is basically full with loads of other methods similar to DoSomething()

So the client will basically create an instance of the facade class, and gain access to all these methods.

My question now is, is this the best practice for a facade pattern? I feel that the facade class is way too "heavy" and I'm not sure if it will affect the performance if my application scales bigger.

Will creating an instance of the facade class be a very expensive operation if I have loads of methods in it?

Answer 1

Well, Facade is highly adequate for SOA architectures, once it encapsulates a subsystem as an object and provides an aggregated interface for all business objects and services to your client. It also reduces the coupling in your architecture. I think your approach isn't heavy, and won't affect the scalability of your system.