Skip to Content.
Sympa Menu

patterns-discussion - RE: [patterns-discussion] Any Data access pattern for accessing data across subsystems ?

patterns-discussion AT lists.cs.illinois.edu

Subject: General talk about software patterns

List archive

RE: [patterns-discussion] Any Data access pattern for accessing data across subsystems ?


Chronological Thread 
  • From: <sayan.mukherjee AT iflexsolutions.com>
  • To: <patterns-discussion AT cs.uiuc.edu>
  • Cc: <SOURAVM AT infosys.com>
  • Subject: RE: [patterns-discussion] Any Data access pattern for accessing data across subsystems ?
  • Date: Tue, 22 Jun 2004 13:58:21 +0530
  • Importance: normal
  • List-archive: <http://mail.cs.uiuc.edu/pipermail/patterns-discussion/>
  • List-id: General talk about software patterns <patterns-discussion.cs.uiuc.edu>
  • Priority: normal

Hi Sourav,

- Let us assume that the 3 subsystems are A, B and C.
- These subsystems are possibly a collection of components like A1, A2,
B1, B2, B3, C1, C2 and so on.
- Each of these components is possibly a collection of interfaces and
implemented classes.
- The implementation of the classes access database tables which they do
not share (#1 and #2).
- In certain cases such cross-access is required (#3).

If the situations under which such cross-access will be required is
known (deterministic)
then a separate set of interfaces and implementations can be created to
cater to these
requirements. These interfaces and implementations can be bundled in
components inside a
'common' and 'separate' subsystem, say X. So X1, X2 etc will be
components with the common
feature that each of them access tables that span across A, B and C.

The behavioural GoF Design Pattern 'Mediator' can be used here. In this
scheme, the subsystems
will constitute the Colleagues and the mediator will be a thin component
which will route
requests to the proper Colleague.

The performance advantage can be derived by the proper design of the
component X depending on
the usage intensity. Preemptive loading and other similar techniques can
be used to achieve the
desired performance from the subsystem X.

I don't know whether this answers your query. Do get back to the forum
with your views.

With best regards,
Sayan


# -----Original Message-----
# From: souravm
[mailto:SOURAVM AT infosys.com]

# Sent: Tuesday, June 22, 2004 10:05 AM
# To:
patterns-discussion AT cs.uiuc.edu
# Subject: [patterns-discussion] Any Data access pattern for
# accessing data across subsystems ?
#
# Hi All,
#
# I'm looking for a design pattern for accessing data across
# multiple subsystems.
#
# To elaborate -
#
# 1. Let us assume that there are 3 functionally independent
# subsystems in a system being designed.
# 2. The interaction happens between these subsystems through
# messages at the business layer of each subsystem.
# In this way no subsystem accesses the table(s) of other
# subsystem directly.
# 3. However, for performance optimization, it might be needed
# that for certain cases one subsystem need to access tables
# of other subsystems through JOINs.
#
# In this situation I'll like to know if there is any specific
# pattern used for implementing a performance trade off
# described in point 3 ?
#
# My aim is to achieve the above mentioned performance goal as
# well as retaining the modularity of the subsystems as much
# as possible.
#
# Any pointer/insight/information will be really appreciated.
#
# Regards,
# Sourav
#
#
# _______________________________________________
# patterns-discussion mailing list
#
patterns-discussion AT cs.uiuc.edu
# http://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion
#


DISCLAIMER:
This message contains privileged and confidential information and is intended
only for the individual named.If you are not the intended recipient you
should not disseminate,distribute,store,print, copy or deliver this
message.Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.E-mail
transmission cannot be guaranteed to be secure or error-free as information
could be intercepted,corrupted,lost,destroyed,arrive late or incomplete or
contain viruses.The sender therefore does not accept liability for any errors
or omissions in the contents of this message which arise as a result of
e-mail transmission. If verification is required please request a hard-copy
version.





Archive powered by MHonArc 2.6.16.

Top of Page