Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > MVC design questions

Reply
Thread Tools

MVC design questions

 
 
Martin Gregorie
Guest
Posts: n/a
 
      02-10-2009
I'm developing a database system that includes both command line and GUI
programs. As both GUI programs need to display fairly large amounts of
data, much of it dependent on precious decisions by the user, they both
use a number of screens this type of relationship:
initial screen - prompt for selection criteria
pop-up screen displaying a selectable list
pop-up screen showing the selected item's details

These programs use the MVC model. Currently each program has one Model
and one Controller to handle data and refresh requirements for all the
screens. Pop-ups are controlled by list selection listeners and action
listeners. The model interacts with the database through a JDBC access
layer, implemented as a single class that contains all SQL statements and
JDBC operations.

Question: Is this a common way of managing a multi-window GUI or is
it more usual to have a separate MVC triad for each window?


I've implemented a separate Model class and database access class for
each program. These are subclasses of Model and database access super-
classes that were intended to contain just common operations such as db
open/close and error diagnostics. However, to make some window classes
usable in both GUI programs, its necessary to use super-class references
in them and this in turn has required virtually subclass methods to have
stubs in the super-class. Worse, many have to be concrete, overridable
stubs rather than abstract or stuff won't compile. The result works OK
but is getting somewhat untidy.

Question: Would it be better to get rid of the subclasses by pulling
their code into the current super-classes in place of the
method stubs?

Question: Would the situation be helped by using Interface
definitions? I'm not using t5hem at present.

Question: Is there a book you'd recommend that covers these aspects
of application design?

The code is running reliably at present and with adequate performance
apart from a couple of queries that I haven't yet optimized. However, as
I said, its a bit untidy in places so some refactoring would be
beneficial. I'm posing these questions now so as to, hopefully, avoid
diving into some refactoring black hole.

TIA,
Martin


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      02-10-2009
Martin Gregorie <(E-Mail Removed)> writes:
>Question: Is this a common way of managing a multi-window GUI or is
> it more usual to have a separate MVC triad for each window?


The leading verb »Is« and the trailing question mark »?«
already mark your sentence as being a question. Some readers
might be offended when you seem to imply that they may not
notice this, but need additional markup to recognize questions.

If someone indeed reads so superficially or is so challenged
that he will not immediatly recognize a question without
additional help, does he belong the the intended circle of
your readers?

I do not have a good overview, but I assume that usually there
is a triad per UI element (window, widget, gadget, component,
...).

Swing does not use MVC directly, but a modfication including
»UI delegates«. In this case, there is on UI delegate per
UI element.

>However, to make some window classes usable in both GUI
>programs, its necessary to use super-class references in them


I do not really understand this. I used to believe that, in Java,
each class (possibly, except »java.lang.Object«) would know
its superclass. Therefore, I can not answer to the rest.

 
Reply With Quote
 
 
 
 
RedGrittyBrick
Guest
Posts: n/a
 
      02-10-2009

Martin Gregorie wrote:
> I'm developing a database system that includes both command line and GUI
> programs. As both GUI programs need to display fairly large amounts of
> data, much of it dependent on precious decisions by the user, they both
> use a number of screens this type of relationship:
> initial screen - prompt for selection criteria
> pop-up screen displaying a selectable list
> pop-up screen showing the selected item's details
>
> These programs use the MVC model. Currently each program has one Model
> and one Controller to handle data and refresh requirements for all the
> screens. Pop-ups are controlled by list selection listeners and action
> listeners. The model interacts with the database through a JDBC access
> layer, implemented as a single class that contains all SQL statements and
> JDBC operations.
>
> Question: Is this a common way of managing a multi-window GUI or is
> it more usual to have a separate MVC triad for each window?



I often share a model between a list-view and a detail-view. For viewing
purposes the detail view doesn't need access to the model, only to a
single DTO or domain object provided by the model. In the list
controller, in response to a "view detail" event I instantiate a detail
view and pass a DTO object to an init() method of the detail view.

>
>
> I've implemented a separate Model class and database access class for
> each program. These are subclasses of Model and database access super-
> classes that were intended to contain just common operations such as db
> open/close and error diagnostics. However, to make some window classes
> usable in both GUI programs, its necessary to use super-class references
> in them and this in turn has required virtually subclass methods to have
> stubs in the super-class. Worse, many have to be concrete, overridable
> stubs rather than abstract or stuff won't compile. The result works OK
> but is getting somewhat untidy.


My experience is probably similar except that I have far more abstract
methods than overridable ones. The only overridable ones I have are for
default behaviours and are rarely overridden. My model superclass has
about ten final methods, ten abstract methods and two overrideable
concrete methods which essentially return null results.

>
> Question: Would it be better to get rid of the subclasses by pulling
> their code into the current super-classes in place of the
> method stubs?


I'm not sure I understand. I've aimed to get *all* common code into the
super-classes. This doesn't remove the subclasses entirely, at least,
not without a lot more thought than I've given it.

In essence, my model subclasses provide the superclass with SQL
constructs specific to certain tables or business domain contexts. They
also extract a specific DTO from the ResultSet obtained by the
superclass. The DTO is basically the generic parameter for the
superclass. The superclass handles all the common overhead of
connections, transactions error-handling etc. IIRC It provides all the
methods needed by my views and controllers. This works well for 95% of
my cases so far. I have a couple of dozen subclasses. Occasionally it is
messy (the other 5%).


--
RGB
 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      02-10-2009
On Tue, 10 Feb 2009 16:24:23 +0000, Stefan Ram wrote:

> Martin Gregorie <(E-Mail Removed)> writes:
>>However, to make some window classes usable in both GUI programs, its
>>necessary to use super-class references in them

>
> I do not really understand this. I used to believe that, in Java, each
> class (possibly, except »java.lang.Object«) would know its superclass.
> Therefore, I can not answer to the rest.
>

Its really being used the other way up at present. Consider a class
defining a window that can be used either to update, insert or delete
items in a list or to simply display items from the in response to a
query. It calls methods in the model superclass to fill its fields and
has an action listener that can apply changes to the database if the
window is being used in edit mode.

The Model superclass delegates these to a program-specific Model subclass
because, in general the model used by updating program will not be the
same as that in the query program. For instance, the updating program
might be maintaining a flat list of all addresses used by a company
while the query program shows a subset of addresses, e.g. those of
offices nearest a city or those of employees who are heating engineers.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      02-10-2009
Martin Gregorie <(E-Mail Removed)> writes:
>Its really being used the other way up at present. Consider a class
>defining a window that can be used either to update, insert or delete
>items in a list or to simply display items from the in response to a
>query. It calls methods in the model superclass to fill its fields and
>has an action listener that can apply changes to the database if the
>window is being used in edit mode.


»The optional extends clause in a normal class declaration
specifies the direct superclass of the current class.«
¯¯¯¯¯¯¯¯¯¯
Java Language Specification, Third Edition, 8.1.4

A window class rarely extends its model.

You possibly use the word »superclass« in another sense
than the Java Language Specification, Third Edition.

 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      02-10-2009
On Tue, 10 Feb 2009 17:18:02 +0000, RedGrittyBrick wrote:

> I often share a model between a list-view and a detail-view. For viewing
> purposes the detail view doesn't need access to the model, only to a
> single DTO or domain object provided by the model. In the list
> controller, in response to a "view detail" event I instantiate a detail
> view and pass a DTO object to an init() method of the detail view.
>

That's good to know since that's essentially what I'm doing.

> My experience is probably similar except that I have far more abstract
> methods than overridable ones. The only overridable ones I have are for
> default behaviours and are rarely overridden. My model superclass has
> about ten final methods, ten abstract methods and two overrideable
> concrete methods which essentially return null results.
>

I'd hoped to do exactly that, but most of my initially abstract stubs
caused compilation errors that would only vanish when I converted them
into concrete dummy stubs. I don't fully understand why.

>
>> Question: Would it be better to get rid of the subclasses by pulling
>> their code into the current super-classes in place of the
>> method stubs?

>
> I'm not sure I understand. I've aimed to get *all* common code into the
> super-classes. This doesn't remove the subclasses entirely, at least,
> not without a lot more thought than I've given it.
>

Thanks - for the time being I'll just move the one or two common subclass
methods into the super-class and then mull over the situation some more.

FWIW separating out the JDBC layer from the model layer was an early
decision but I was undecided whether to lump JDBC access for all programs
into one system-wide class or to have one class per program. I eventually
decided to go with the second idea plus a super-class to hold the common
elements but am wondering if that was the right decision.

> In essence, my model subclasses provide the superclass with SQL
> constructs specific to certain tables or business domain contexts. They
> also extract a specific DTO from the ResultSet obtained by the
> superclass. The DTO is basically the generic parameter for the
> superclass. The superclass handles all the common overhead of
> connections, transactions error-handling etc. IIRC It provides all the
> methods needed by my views and controllers. This works well for 95% of
> my cases so far. I have a couple of dozen subclasses. Occasionally it is
> messy (the other 5%).
>

This system has a really simple schema - just 5 tables, one sequence and
one view that's never used by Java code.
- the sequence is used by one program.
- all the Java programs need to access the main set of 4 tables,
which form a star schema with one M:M dimension.
- the remaining table is used by one program to control the activity
of a second. The two programs never run simultaneously.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      02-10-2009
On Feb 10, 1:58*pm,
RedGrittyBrick wrote:
>> My experience is probably similar except that I have far more abstract
>> methods than overridable ones. The only overridable ones I have are for
>> default behaviours and are rarely overridden. My model superclass has
>> about ten final methods, ten abstract methods and two overrideable
>> concrete methods which essentially return null results.

>


Martin Gregorie wrote:
> I'd hoped to do exactly that, but most of my initially abstract stubs
> caused compilation errors that would only vanish when I converted them
> into concrete dummy stubs. I don't fully understand why.
>


Can you work up and post an SSCCE that demonstrates this issue? I'm
very intrigued.

--
Lew
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      02-10-2009
[I think i have rather low levels of blood sugar and caffeine right now,
so some of what i write may be stupid - apologies if so. I'm also asking a
lot of questions the answers to which may not have any bearing on the
solution sought.]

On Tue, 10 Feb 2009, Martin Gregorie wrote:

> I'm developing a database system that includes both command line and GUI
> programs. As both GUI programs


'Both GUI programs'? Do you have multiple GUI programs, plus the CLI one?
If so, how do the GUI programs differ?

> need to display fairly large amounts of data, much of it dependent on
> precious decisions by the user, they both use a number of screens this
> type of relationship:
> initial screen - prompt for selection criteria
> pop-up screen displaying a selectable list
> pop-up screen showing the selected item's details


Can you have several initial windows open at once? Can you have several
list windows per initial? Several details per list?

> These programs use the MVC model. Currently each program has one Model
> and one Controller to handle data and refresh requirements for all the
> screens. Pop-ups are controlled by list selection listeners and action
> listeners. The model interacts with the database through a JDBC access
> layer, implemented as a single class that contains all SQL statements
> and JDBC operations.
>
> Question: Is this a common way of managing a multi-window GUI or is
> it more usual to have a separate MVC triad for each window?


I have a definite preference for one model across the whole system. One
model object per domain entity - the last you thing you want is multiple
Inmate objects representing the same inmate.

As for controllers - i tend to think one controller per UI assembly.
Although if they're stateless, you can share them. But then, if they're
stateless, they're small, so there's no harm in not sharing them.

And that just begs the question of what a 'UI assembly' is. You could have
one per initial window, doing controlling for that window and its list
popups, or one for each different window, initial and popup. There, i
think i'd go for one per window - make each controller as simple as
possible, handling the events and updates for just one window. If your
windows are complicated, with several panes or widgets or whatever, then
perhaps even one per part of a window.

> I've implemented a separate Model class and database access class for
> each program. These are subclasses of Model and database access super-
> classes that were intended to contain just common operations such as db
> open/close and error diagnostics. However, to make some window classes
> usable in both GUI programs, its necessary to use super-class references
> in them and this in turn has required virtually subclass methods to have
> stubs in the super-class.


I don't follow. You need the methods in the base class which are needed to
support the windows common to the two apps - by definition, those are the
the methods which are intrinsically common to the base model. Why are the
other methods brought in? Are they called from the common methods,
template-style?

Or are you making all references to the model object references to the
base type, even in the app-specific code? That would indeed require all
methods to be stubbed in the base class, even when they were app-specific.
Like:

class BaseModel {}

class FooModel extends BaseModel {}

class BaseApp {
protected BaseModel model;

private void handleSomeKindOfEvent() {
model.doGenericThing();
}
}

class FooApp {
private void handleSomeOtherKindOfEvent() {
model.doFooSpecificThing();
}
}

If you have code like that, then you need doFooSpecificThing in BaseModel,
as well as doGenericThing. But the soluion isn't to do that, it's to
refactor FooApp:

class BaseApp {
protected abstract BaseModel getModel();

private void handleSomeKindOfEvent() {
getModel().doGenericThing();
}
}

class FooApp {
private FooModel model;

protected abstract BaseModel getModel() {
return model;
}
private void handleSomeOtherKindOfEvent() {
model.doFooSpecificThing();
}
}

That lets you put doFooSpecificThing in FooModel.

There's another way to do it, with a BaseModel reference in BaseApp, and
lots of casting, but that's not nice.

There's also a way to do it involving generics.

Is that anything like the situation you've got?

> Worse, many have to be concrete, overridable stubs rather than abstract
> or stuff won't compile.


That sounds really odd. Like Lew, i'd love to see some code here.

> The result works OK but is getting somewhat untidy.
>
> Question: Would it be better to get rid of the subclasses by pulling
> their code into the current super-classes in place of the
> method stubs?
>
> Question: Would the situation be helped by using Interface
> definitions? I'm not using t5hem at present.


No. They won't do anything you can't do with classes and abstract methods.
They might be a better way of doing things, but they won't actually solve
problems.

> Question: Is there a book you'd recommend that covers these aspects
> of application design?


There are no books that teach the skill of OO design but your own diary,
and no schools but the school of hard knocks.

Although Design Patterns and Refactoring are both pretty good.

tom

--
I was employed by a Lacanian and, believe me, you don't want to see what
a postmodern approach to cashflow entails. -- G'
 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      02-10-2009
On Tue, 10 Feb 2009 18:37:39 +0000, Stefan Ram wrote:

> A window class rarely extends its model.
>
> You possibly use the word »superclass« in another sense than the Java
> Language Specification, Third Edition.
>

Not intentionally.

Lets see if a diagram is a clearer explanation of what I'm doing:

MessageWindow - used by programs MASearch and MAUpdate
| along with MessageWindowAction
|
MAModel (superclass) - contains no data or methods
| |
MASModel | - model used by the MASearch query program
MAUModel - model used by the MAUpdate db maintenance prog


The methods in the model used to support MessageWindow are implemented in
MASModel and MAUModel and are not necessarily the same. MAModel is purely
a shell containing abstract methods (or concrete overridden methods where
the system won't compile if they are declared abstract). This is done so
that MessageWindow doesn't know that its actually using MASModel in
MASearch and MAUModel in MAUpdate.

The window hierarchy is very different for the two programs:

MAUpdate MASearch
address list window[1] search criterion setting window
AddressDialogue window[2] message list window[3]
MessageWindow MessageWindow


[1] this list contains a selectable list of all addresses.
Selecting one displays its details in an AddressDialogue window,
ready for amendment or deletion.

[2] AddressDialogue contents includes a selectable list of messages
associated with the selected address. Selecting a message displays
it in a MessageWindow, which allows the message to be inspected
and optionally deleted.

[3] this list contains a selectable list of messages meeting the message
search criteria. Selecting one displays it in a MessageWindow,
which allows the message to be inspected and optionally sent to
a recipient.

The only difference between the appearance of the MessageWindow is that
when MASearch uses it you see Send and Exit buttons while MAUpdate shows
Delete and Exit buttons.

If there is a way to achieve this elegantly without needing the MAModel
super-class I'd be very pleased to be steered in that direction.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      02-10-2009
On Tue, 10 Feb 2009 11:17:06 -0800, Lew wrote:

> On Feb 10, 1:58Â*pm,
> RedGrittyBrick wrote:
>>> My experience is probably similar except that I have far more abstract
>>> methods than overridable ones. The only overridable ones I have are
>>> for default behaviours and are rarely overridden. My model superclass
>>> has about ten final methods, ten abstract methods and two overrideable
>>> concrete methods which essentially return null results.

>>
>>

> Martin Gregorie wrote:
>> I'd hoped to do exactly that, but most of my initially abstract stubs
>> caused compilation errors that would only vanish when I converted them
>> into concrete dummy stubs. I don't fully understand why.
>>
>>

> Can you work up and post an SSCCE that demonstrates this issue? I'm
> very intrigued.
>

I'll try, but don't hold your breath!

In the meantime, my understanding is that, if I declare all but the
common methods as abstract, then I'm free to override the ones provided
by each subclass and ignore the rest BUT, as I call the subclass methods
via the super-class, there must be an abstract method declared for every
method in all subclasses.

If this is a total misuse/misunderstanding of class hierarchies I'd
appreciate correction or pointers to suitable tutorials.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
No MVC Project Template after installing ASP.NET MVC 1.0 Crazy Cat ASP .Net 1 09-03-2009 08:02 PM
WebForms X MVC? Why MVC? Give me reasons to migrate my web apps to it please. Pros x Cons! Thanks! Paulo ASP .Net 3 12-04-2008 03:00 AM
differences between Spring WebFlow,Spring MVC,and String Portlet MVC? rmn190 Java 2 01-10-2008 02:27 AM
EJB / MVC Design MP Java 4 11-06-2003 12:07 AM
Any gd example for MVC Design in ASP.NET ? winglite ASP .Net 1 11-03-2003 05:03 AM



Advertisments