Re: Data access from multiple code modules

simon.hibbs@xxxxxxxxx wrote:
Bruno Desthuilliers wrote:


Do you mean the code effectively doing these operations is in the gui ?
If yes, it would be better to factor it out IMHO.

The GUI has to be able to acces the data object, otherwise how does the
user affect any changes to the application data? If I modify a value in
a text box and hit Apply, that change must be propagated to the data
model somehow.

Yes, obviously. But that's not what I said. My advice is to seperate the
GUI code (view) from the code operating on data (controler), so
operations are independant from the GUI code itself. Of course the view
needs to call back on the controler(s), and the controler(s) need to
have a refence to the model.

Similarly, the GUI must access the data to display it.

Yes, obviously. But here again, it may be better to just have the GUI
call back on the controler(s) to get needed data.

Actualy this has nothing to do with code modules. The problem is is you
have one object that contains your data, and your app consists of
several objects that need to interact with it, how do these other
objects access it?

I'm fairly new to OOP and Python so I don't know
it's scoping rules very well.

Simple example:

One way would be to use the database as the point of contact for all
the object. Every object that wants to read or write to the database
instantiates an object to interact with the database and performs
whatever actions it needs.

If by "any object", you mean "any GUI widget", then this his how
languages like VB and Delphi (and other "DB->GUI pipeline" tools) work,
and it's an approach that is known to have some drawbacks.

That way each top-level objecyt will contain
it's own instanced database IO object. Their only point of contact with
each other is the database itself. This could lead to synchronisation
problems though.

Another way would be to create one instance of the database IO object
and then pass it as a parameter to the other application objects when
they are created. The point of contact between the application objects
would be the single database IO object, with the database behind it.
This seems to me to be the superior approach.

I don't know enough of your "database IO object" and "other application
objects" is a too vague definition, so I can't really comment on this,
but it seems like we are in the same situation as above.

Are there any other architectural options that anyone could suggest?

Separating operations on data (model/controler) from GUI code (view).
The controler(s) have a reference on the model. The views have a
reference on the controler(s), and call on the controller to get data to
display or act on data.

My 2 cents
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xxxxxxxxxxx'.split('@')])"
.

Relevant Pages

  • Re: Complex Windows Applications in C# -- how high is the bar?
    ... child windows containing various Windows controls, ... application in order to stretch it to handle an enitrely new database ... concern is the GUI -- this is a very complex application in terms of its ... There's nothing wrong with letting the complex GUI stuff remain in the hands of Win32 code and use managed code for the database access, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: porting curses driven to gui application
    ... > more than just replace the curses interface by a GUI. ... > don't have a X server (e.g. because they are just running Windows ... > running on the machine where the database is also running. ... > server and the client on the user side. ...
    (comp.unix.programmer)
  • Re: The future of Linux
    ... Occasionally, I might use a spreadsheet, wordprocessor, or database. ... depending on the selection of OS your work uses. ... "bash history" that remembers your commands and allows you to search ... talking to remote databases without a GUI overhead across the network. ...
    (comp.os.linux.misc)
  • Re: OOP/OOD Philosophy
    ... >foreign key, the GUI will not be unaffected. ... >> Let's finally say that the GUI code depends deeply on the database ... >> that relationship table was not put into the GUI code. ...
    (comp.object)
  • Re: Advice on Architecture
    ... abstraction from the database. ... My recommendation: for all your lookup data: ... You can simply store the array of DataRow objects and pass it ... If you are going to make a connection, get data, fill some GUI, and not ...
    (microsoft.public.dotnet.general)