[tssg-tech] Re: research on Adapters (what, why, when and how)

  • From: Jim Cant <cant_jim@xxxxxxxxxxx>
  • To: tssg tech <tssg-tech@xxxxxxxxxxxxx>
  • Date: Sat, 30 Oct 2010 10:48:23 -0400

Hi team,

Let me respond to Harry's post by explaining how EventBoss could work given our 
architecture and where the MVC (Model/View/Controller) design pattern fits in.

Actually, our architecture is agnostic about MVC; it doesn't know whether or 
not the MVC design pattern is used within the application or not.

Here's how the core/UI module might function within our apps overall 
architecture.  (I say 'might' because all this happens within the core/UI 
module whose internal architecture is not specified.)
1. App starts.
2. Creates an object to implement the data model.  (This object is an instance 
of a class that's part of the core package; it's not an Android thingy.)
3. Retrieves data from the eventsource and adds to data model.
4. Retrieves data from the datastore and adds to the data model.
5. Creates the object to implement the view.
6. Tells the view about the model. (passes a reference to the data model (or 
adapter, see below) to the view
7. Tells the view to display.
8.  .....user does what users do.....
9. When app closes, persist any changes to the  datastore.

An adapter may or may not be needed depended  on how well the data model and 
view can play together on their own.  If the view wants to call "getCount()" on 
the data model and the data model  has such a method, everything is fine.   If 
the data model has a method named "getSize()" that returns the count, then you 
need an adapter that knows about the data model.  The adapter would have a 
method something like 'int getCount() { return myDataModel.getSize(); }.  Now 
instead of passing the data model directly to the view (#6 above),
you pass the data model to an adapter instance and pass that to the view; now 
the view and data model can play together because the adapter is acting as an 
'interpreter' between the different 'dialects' of data model and view.

You don't need an adapter for an active model.  What is needed is to register 
the view (in some manner) with the data model so the data model can notify the 
view when the data is changed.  I believe the Observer design patter is called 
for here.

Here's a nit to pick from the sequence of events you mention:
        (2) The CONTROLLER responds by sending a message to the MODEL, e.g. 
"change stored data".
        (3) Simultaneously, the CONTROLLER notifies the VIEW that the "stored 
data has changed"
the use of 'simultaneously', suggests the possibility of a race condition 
wherein the view could ask the model for the changed data before the model has 
changed the data.


Hope this helps,

jim

Date: Fri, 29 Oct 2010 15:27:58 -0700
From: harry_henriques@xxxxxxxxxxx
Subject: [tssg-tech] Re: research on Adapters (what, why, when and how)
To: tssg-tech@xxxxxxxxxxxxx



Hello team,

We probably should use the "Passive Model" that is explained below.   I think 
that our architecture would look like this:

BTW, I realize that our application isn't a strict HTTP request/response model
Passive Model





 With a passive model, the objects used in the model are completely 
unaware of being used in the MVC triad.  The controller notifies the 
view when it executes an operation on the model that will require the 
view to be updated.  The passive model is commonly used in web MVC.  The strict 
request/response cycle of HTTP
 does not require the immediacy of an active model.  The view is always 
completely re-rendered on every cycle, regardless of changes. This may 
be especially true in PHP where no state is retained between requests.





________________
|               |
| DataStore     |
| MODEL         |
|persist data   |
|---------------|      
| Data Buffer   |------|
--------^--------      |
  find  | store        |
__data__|_data____     |
|                |     |
|  RSS Parser    |     |
|  CONTROLLER    |     |retrieve data
|                |     |
----------^-------     |
update|   | issue     
 |
view  |   | requests   |
------V-----------     |
|                |     |
| User Interface |<-----
|     VIEW       |
|                |
------------------

If I understand the passive MVC design pattern, the following operations occur 
in sequence:

(1) A widget in the VIEW is activated.  It sends a message to the CONTROLLER, 
e.g. "get RSS feed"
(2) The CONTROLLER responds by sending a message to the MODEL, e.g. "change 
stored data".
(3) Simultaneously, the CONTROLLER notifies the VIEW that the "stored data has 
changed"
(4) The VIEW responds by retrieving data from the MODEL and populating the 
presentation layer.

The MODEL doesn't know
 anything about the VIEW.  The MODEL exposes methods that allow the CONTROLLER 
to store data from the RSS Parser, and exposes methods that allow the VIEW to 
retrieve data from it.  The MODEL is completely PASSIVE in this architecture; 
it is completely uncoupled from the CONTROLLER and the VIEW.

Let me know if we agree if this is actually the MVC pattern that we are talking 
about.  I don't think we need a ADAPTER unless we are forced to implement an 
ACTIVE MODEL.

Best regards,
Harry Henriques

<...snip...>                                      

Other related posts: