RE: [Andromda-user] Design question

[Matthias Bohlen]

Title: Nachricht

Hi Gerard,   OK, now I think I understand! :-)   I would recommend to think of the facade as a service that realizes your use case or a use case package. So, the facade should contain methods that support the flow of your use case(s). The facade should (if possible) not expose details about which entities it uses, creates or deletes.   If you want your presentation layer to be absolutely independent of the technology in which your business tier is written, you have to use things like "service locator" (a pattern) and "business delegate" (also a pattern). You will find these patterns in the literature about enterprise architectures (e.g. TheServerSide.com, etc.).   What did you mean exactly when you said: "the presentation layer shouldn’t have any of the business tier" ?   Cheers... Matthias -----Original Message----- From: Gerard Gill [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 5:27 AM To: 'Matthias Bohlen' Subject: RE: [Andromda-user] Design question Hi Mathias,   Sorry I was in a rush and tired. I am writing a standard for the new development platform (ASP.NET) for my company. The requirements are as follows:  -Reduce the time spend on coding. - built a fully reusable structure presentation tier, business tier and data access tier - the presentation layer shouldn’t have any of the business tier   I’m considering taking up Façade structure, but I don’t know much about it. I have implemented a demo to represent the standard as follow  -  One client class -  One myFacade class  - Two subsystem classes’ i.e. employee class and employer class   I want both subsystem classes be accessible by the client class via myFacade class, so some how I have to add some additional identified or parameter to myFacade class to know which class to delegate the parameter to right. Or have specific function in myFacade class for each subsystem class. As a result I’ll end up with a massive myFacade class.   So my question is from your experience point of view what do you think is the best approach to the above scenario?   Thank you   Gerard Gill               -----Original Message----- From: Matthias Bohlen [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 11, 2004 3:27 PM To: 'Gerard Gill' Subject: RE: [Andromda-user] Design question   Hi Gerard,   I am sorry but I did not understand what you mean.   Cheers... Matthias -----Original Message----- From: Gerard Gill [mailto:[EMAIL PROTECTED] Sent: Thursday, March 11, 2004 11:59 AM To: [EMAIL PROTECTED] Subject: RE: [Andromda-user] Design question Importance: High Hi Matthias   I need your expertise, I writing a new standard for ASP.NET application, I’m intend to use Façade example   Class client() {}   Class MyFacade()   Class subsystem1() Class subsystem2()   Class myDataAcess()   I want to make these entire tiers to be re usable and also I want client class to able to access both Subsystem but I don’t want to hardcore at client side (i.e instantiated subsystem class). Somehow I want to create other class that would hold the entire system class name What would you recommend?   Thank you in advance         > Hi Ingo and the others,   Tony already said most of the interesting things. From my experience as a software architect in several projects, I'd like to add a word of warning: :-)   > I have modeled a class FooFacade with the stereotype <<Facade>>. This > class has associations to the Entity classes (<<EntityRef>>) which > should be accessed via this facade. So i generate this facade with > some createing, accessing (vo's) and removeing functions for each > association.   It may seem tempting to generate all these CRUD (create,read,update,delete) functions for your entities into the session facade. However, doing this, you expose the internals of your component across the facade to the client! The facade does not deserve its name any more.   Example:   class MyFacade {     public XValue createX();     public XValue findX(key);     public void updateX(XValue);     public void deleteX(key);       public YValue createY();     public YValue findY(key);     public void updateY(YValue);     public void deleteY(key); }   What if (after three months into the project) you decide to remove entity Y? You'll have to modify a lot of client code that uses the CRUD functions for Y.   I would recommend to put higher-level business methods into the facade that support your particular use case. Create one facade per coherent group of use cases. Adding or deleting one more entity class does not affect those high level methods and you have decoupled your component from your client. Your code will be much easier to maintain.   Tell me if I understood you correctly and if all this makes sense to you...   Cheers... Matthias