O
Olaf Kittelmann
Hi,
After getting some inspiration by reading Adam Bien's J2EE Pattern
book
I am now at the point of the design stage, where the best solution for
my individual need can not be deduced from the examples I know (seems
familiar ?),
and I have to start thinking myself (d'oh).
my design question can be rounded up in one sentence as follows:
- where goes my Value Disassembler - Presentation Layer or Business
delegate ?
let me expand this a bit further:
I will build a ticketing (HelpDesk) System for a portal environment.
I will have one complex form for recording a service request.
The form's input data will be restructured into an aggregate entity,
this means that for example three fields values (customerId,
customerName, customerDept) will form a sub-entity (Customer )of the
aggregate entity (ServiceRequest).
where does the logic for constructing an aggregate entity, from a list
of attributes belong?
I am not sure whether this is Business or Presentation logic
My first guess would be to put it into the BD, but then how silly
would my createServiceRequest method signature look like? (I cannot
imagine passing 25+ parameters)- or do I pass them as separate value
Objects?
Another option would be to split the BDs creation method of a
ServiceRequest into several steps (The dialogue will be implemented in
this wizard type of design anyway).
but this would
a) mean that my BD has to be stateful - which I want to avoid
b) impose a strong coupling between presentation logoc and BD
Another thought that just came to my mind:
The main point why I feel this to belong to the BD is that the code
for validating the sub entities and ensuring a valid state of my
Service Request seems to fit neatly into the construction of the
aggregate entities' structure.
(but 25 parameters :0 I do not want to see in a method signature with
my name filling the author tag)
please let me know what you think,
regards,
Olaf
After getting some inspiration by reading Adam Bien's J2EE Pattern
book
I am now at the point of the design stage, where the best solution for
my individual need can not be deduced from the examples I know (seems
familiar ?),
and I have to start thinking myself (d'oh).
my design question can be rounded up in one sentence as follows:
- where goes my Value Disassembler - Presentation Layer or Business
delegate ?
let me expand this a bit further:
I will build a ticketing (HelpDesk) System for a portal environment.
I will have one complex form for recording a service request.
The form's input data will be restructured into an aggregate entity,
this means that for example three fields values (customerId,
customerName, customerDept) will form a sub-entity (Customer )of the
aggregate entity (ServiceRequest).
where does the logic for constructing an aggregate entity, from a list
of attributes belong?
I am not sure whether this is Business or Presentation logic
My first guess would be to put it into the BD, but then how silly
would my createServiceRequest method signature look like? (I cannot
imagine passing 25+ parameters)- or do I pass them as separate value
Objects?
Another option would be to split the BDs creation method of a
ServiceRequest into several steps (The dialogue will be implemented in
this wizard type of design anyway).
but this would
a) mean that my BD has to be stateful - which I want to avoid
b) impose a strong coupling between presentation logoc and BD
Another thought that just came to my mind:
The main point why I feel this to belong to the BD is that the code
for validating the sub entities and ensuring a valid state of my
Service Request seems to fit neatly into the construction of the
aggregate entities' structure.
(but 25 parameters :0 I do not want to see in a method signature with
my name filling the author tag)
please let me know what you think,
regards,
Olaf