Some design questions

[tobias.sturn]

Hi everybody!

I have some design questions and i would be very interessted what you
think?

- Where, when and who should create the gui, guicontroller,
usecasecontroller, domainlayer, db in a layer architecture?

- what should be the the responsabilities of the usecase controller and
the guicontroller?

- Would it be good if the usecasecontroller comunicated directly with
the persistence layer?

- Why should i dont let the gui communicate directly with the
persistence layer?

Thanks a lot!!!

 

[Phlip]

[follow-up set to comp.software-eng]

Hi everybody!

I have some design questions and i would be very interessted what you
think?

- Where, when and who should create the gui, guicontroller,
usecasecontroller, domainlayer, db in a layer architecture?

The team should. Specifically, those things should start as tiny
functions, and the team should integrate them all first, forming a
round-trip application. And only then should team members add features to
each step.

That technique is called a "spike solution". Imagine taking a layer cake,
and sticking a railroad spike through its layers. The spike represents the
first code you write - it spikes down through all layers, and only does a
little bit in each layer. A GUI with only one button, for example.

The rest of the cake represents the team adding features to each layer.
Yet each feature may require edits in more than one layer. Team members
should own features, not layers, and should know how to work on each layer.

- what should be the the responsabilities of the usecase controller and
the guicontroller?

There's no such thing as a "usecase controller". If you mean
Model-View-Controller, their responsibilities are to observe each other
using the Observer Design Pattern.

- Why should i dont let the gui communicate directly with the persistence
layer?

Encapsulation is hierarchical. That means the further the conceptual
distance between two program modules, the narrower their communication
should be.

Ideally, a change in one place should not require changes in too many
other places. You should be able to add GUI controls without adding
database fields, and vice versa. Plugging a GUI directly into a database
often prevents you from changing one without changing the other.