3

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?

Null Reference
  • 11,260
  • 40
  • 107
  • 184

2 Answers2

3

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.

Alcides Queiroz
  • 9,456
  • 3
  • 28
  • 43
  • So it's ok for a Facade class to have say, for example, 60 over methods to encapsulate all the inner workings of sub systems? – Null Reference Oct 05 '12 at 06:35
  • 2
    Though this approach reduces the cohesion of your API exposition, if it accomplish the four main objectives of the pattern, I think it's OK: 1) make a software library easier to use, understand and test, since the facade has convenient methods for common tasks; 2) make the library more readable, for the same reason; 3) reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system; 4) wrap a poorly designed collection of APIs with a single well-designed API (as per task needs). – Alcides Queiroz Oct 05 '12 at 11:21
  • 1
    If your facade simplify the use of your subsystem, there's no problem in expose such number of methods, that's the idea. Obviously, if your facade doesn`t needs to persist some individual state per instance (and probably doesn`t), you will implement it as a singleton (this is the most common scenario), what is cheap. – Alcides Queiroz Oct 05 '12 at 11:29
  • I wouldn't worry about how heavy the class is especially if it's stateless and can exist as a singleton. The more loosely coupled your API, the easier it is to scale horizontally. – Coder Guy Oct 10 '14 at 17:34
0

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.).

Community
  • 1
  • 1
BlackjacketMack
  • 5,472
  • 28
  • 32
  • I know this is a bit old, but you are right that the number of methods really shouldn't have any effect. Methods are JIT compiled, so you can have 100 methods and only use 2. So then only 2 will be compiled at runtime. – Johnathon Sullinger Dec 07 '14 at 04:46