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.

Answer 2

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

Assuming those methods are not called during construction they should have no impact on the 'weight' of the object. My understanding is that a method that isn't doing anything doesn't cost memory or cycles for practical purposes.

(as a side note, there are technical limits that don't add value to your question. see How many methods can a C# class have)

Make your facade work for you! A good practice is to assume you're handing it over to someone else and ask "does this neatly describe what the capabilities of my API are?". Sixty sounds like it's reaching the upper-bounds of my personal preference but that's still only CRUD for 15 objects.

Think of the facade as a unified interface that frees you up to create more concise and sophisticated Services (which in turn should encapsulate even more concise repositories which in turn should encapsulate even more concise records of data in tables, BLOBS in buckets, etc.).