Re: advise on best practices guides and projects
Mark Space wrote:
tom forsmo wrote:
Huh. After reading through the Head First Design Patterns book, I got
the exact opposite impression. Design patterns are very small scale,
tactical bits of software. Sure, knowing about them influences your
overall design because you want to take advantage of handy bits, but
thats true of any design that reuses bits.
I like to think of programming techniques in three levels
architecture --> design --> oo idioms
As you say, many of the GoF patterns are tactical bits of software
(lower end of design, by my definitions), e.g. Singleton, Iterator,
Strategy, Template Method. But many of them are more relevant for
architectural issues (upper end of design) such as Abstract Factory,
Builder, Adapter, Facade, Command, Mediator, State, Visitor. The
difference is how much does it affect the system as a whole. Some
patterns just affect the next class. i.e. the one using it, other
patterns have a much wider reach and influences how entire modules
operate or even across modules. Those patterns are architectural, such
as Business Delegate, Data Access Objects, Data Transfer Objects,
Service locator, Domain Model, messaging patterns. etc
If you'd like to talk about one or two patterns from that book (because
I have the same book and I could refer to it) we could talk about, maybe
have some other folks chime it.
Ok, let me get back to you on that one. I need to think a little, but
two patterns of major interest comes to mind. Strategy, because its the
essence of OO programming and DAO because its deals with a common
problem, arguments and results. (Of course other patterns also exude the
essence of OO, such as template method, decorator, abstract factory, but
we will have to start somewhere)
I usually code store-and-retrieve servers connected to an sql
This I don't have much practical experience. Maybe if you described a
bit more though we could try to shed some insight. It sounds to me
though that you're working at a level where the actual design is
minimal, and you could (and probably should) be using as many automated
tools as possible.
I'm my limited experience, that's a big reason for those "extra" layers
to exist. They are understood by, and possibly generated by and
maintained by, automated code systems.
I was thinking about this yesterday and I remembered something I had
forgotten, which highlights the reasons for extra layers. There is a
difference between technical systems and business systems. Technical
systems don't have much domain logic, but they do have lots of
algorithms and solutions to technical requirements such as
- performance reqs --> caching, communication model, concurrency model
- stability reqs --> caching, error and exception handling, correctness
- algorithms and protocols
I am not saying a business system does not have these things, only that
these are the things a techincal system usually involves.
A business system, in addition, has
- a domain model,
- domain logic
- etc
So there is of course fewer layers and the layers are thinner. But the
layers contains techincal solutions instead of business solutions.
The following is a model I mostly use
Facade layer(SOAP) ---> Domain layer ---> DB layer ---> DB(Postgres)
- The Facade would contain code that receives the externall calls and
convert the communication layer data models to the servers internal data
model. The conversion should happen here because then the interface of
the domain layers does not need to change when you change the
communication method of the facade layer. That way one can have several
comm methods on a single domain interface/api.
The layer also contains code that log the requests and perform comm
layer management and exception handling. It also could contain code that
performs security checks, which depends on the comm layer type.
- The domain layer has three purposes,
1) to act as a server facade,
2) perform domain logic (such as parsing, command data retrieval from
different sources) and
3) manage the technical solutions of the technical requirements (such
as final error and exxception handling (exception barrier),
stability issues, performance issues, selfpreservation and so on)
- The DB layer has its own facade/api which the responsibility of
converting the domain model arguments into a relational model or vice
versa before respectively storing data and after retrieving data.
In addition it must manage the db communication model (such as single
inserts or batch, transactions, exceptions and so on.)
- The DB holds the datamodel in terms of table defintions, indexes,
stored procedures and so on.
So by remembering this fact I have sort of solved some of the
architectural questions I originally had. It does help, just to try to
explain things to others. :)