Re: A Dialogue

Joe Pluta wrote:

From: Thorbjørn Ravn Andersen

I try to learn what I can from everyone, and there are certainly concepts in
academic CS that make sense. There are many that don't, but there are some
that do. I love the idea of Design Patterns, for example, and I really
latched onto that concept. In fact, that's what I try to teach to when I am
teaching multi-platform architectures; there are really simple, basic
patterns that we use in all business application programming. For example,
nearly all of what business application programmers do can be broken down
into CRUD and QUERY applications - CRUD (Create, Read, Update, Delete)
handles all your maintenance and QUERY applications are your reports and
inquiries. If you write servers that can support those basic transaction
types, nearly all of your business logic is done and you can focus on your
user interface!

Joe, I agree and this has been our experience also. Many/most applications involve the "foundational" patterns of QUERY + CRUD. Then more complex applications add a "layer" on top of these "foundational" patterns and perform things like validation, computations, workflow, business processes, etc. Within CRUD and QUERY there are several "sub patterns" but are still patterns.

Solve CRUD plus QUERY foundational patterns while allowing add on special case logic you got 60, 70, 80, 90%???? of typical applications solved.

To extend your points, we find may "design patterns" in the UI as well. Patterns such as:

1. (Subfile) I.E a Table of data with x columns and y rows
2. A detail screen (normally single row with more detail than 1.
3. A edit scree (editable version of #2)
4. Inquiry with dynamic selection. (same as 1 except allows selection on certain fields)
5. Drill down - Go from one row to another related set of Row(s)
6. etc... We have identified approx. 30 UI patterns.

Combining everything, CRUD + QUERY + UI patterns, then you have the capability to create application very quickly (often in minutes for applications that follow the basic "patterns" which many do.

Which leads me to another excellent concept: MVC. Model-View-Controller is
one of the best design paradigms to hit the IT world, especially to an old
monolithic green screen dinosaur like me. It simply emphasizes the fact
that your user interface shouldn't have any idea how your business logic
works; if you adhere to that strategy, your work is always a lot easier in
the long run.

I agree that your UI (view) should not have knowledge of "how the business logic" is carried out. The main benefit we strive for is the ability to reuse the business objects in a different environment such as Web browsers or the same logic in web services. This gives you the ability to put a new front end or UI on reusing the same bus logic.

In many cases we have found, that your UI needs to know much about the business model to be effective. Things like:

a. What fields are required on entry / insert
b. What are the possible values of field x based on the current value of field y (based on the STATE, the possible CITIES list values change)
c. etc

This still maintains separation of UI View from business model but allows your business model to "reveal" or supply the UI information that the UI needs to do its job.

This is where the true value of OO and patterns can be exposed.

Joe

My $0.02, Thanks, Paul Holm