Stateless Objects

[Tony Liguori]

I'm sorry to say I have not yet read your book. It's very likely that the
answer to my question may be found there.

All of the 3-tiered application development that I do uses stateless objects
running in MTS. The problem is that you can't properly encapsulate the data
validation or business logic in a stateless object. For instance, you may
want to execute a Property Let from inside a Text1_Change event, then validate
the data from within the Property Let inside the business object. With a
stateful object, this was a useful technique and not a problem.

Do you recommend creating another set of stateful objects for the purpose
of validating data and business rules, or, is there a better way?

Thank you!

Tony Liguori, MCSD

[Deborah Kurata]

One choice is to do a set of stateful objects that run on the client and not
under MTS.

Another choice is to have a validate method in the stateless component. The
downside of this is that the user will not get field by field validation.

Good luck!
Deborah

Tony Liguori wrote in message <38fcd41d$1@news.devx.com>...
>
>I'm sorry to say I have not yet read your book. It's very likely that the
>answer to my question may be found there.
>
>All of the 3-tiered application development that I do uses stateless
objects
>running in MTS. The problem is that you can't properly encapsulate the
data
>validation or business logic in a stateless object. For instance, you may
>want to execute a Property Let from inside a Text1_Change event, then
validate
>the data from within the Property Let inside the business object. With a
>stateful object, this was a useful technique and not a problem.
>
>Do you recommend creating another set of stateful objects for the purpose
>of validating data and business rules, or, is there a better way?
>
>Thank you!
>
>Tony Liguori, MCSD

[Deborah Kurata]

I think it depends on the application and on the user. For all of our Web
stuff, we wait to validation until the user hits the submit button. For much
of our desktop stuff, we do field-by-field validation because of the types
of apps we have done. We don't put up message boxes on errors, so it does
not interfere with heads-down data entry. We try to have ours work like
Word, where it turns errors red so the user can review the errors when the
typing is complete.

- Deborah

>Deborah,
>
> Don't you think field by field validation is a needless hindrance to
>data entry? I do all of my validation when I post. Most data entry folks
>work 'head-down' anyway, and should not be made to contend with field by
>field validation, IMO. Also, this eliminates the problem that is the main
>subject here. What do you think?
>
>Regards,
>D. Patrick Hoerter
>
>Deborah Kurata wrote in message <38fdf780$1@news.devx.com>...
>>One choice is to do a set of stateful objects that run on the client and
>not
>>under MTS.
>>
>>Another choice is to have a validate method in the stateless component.
The
>>downside of this is that the user will not get field by field validation.
>>
>>Good luck!
>>Deborah
>>
>>Tony Liguori wrote in message <38fcd41d$1@news.devx.com>...
>>>
>>>I'm sorry to say I have not yet read your book. It's very likely that
the
>>>answer to my question may be found there.
>>>
>>>All of the 3-tiered application development that I do uses stateless
>>objects
>>>running in MTS. The problem is that you can't properly encapsulate the
>>data
>>>validation or business logic in a stateless object. For instance, you
may
>>>want to execute a Property Let from inside a Text1_Change event, then
>>validate
>>>the data from within the Property Let inside the business object. With a
>>>stateful object, this was a useful technique and not a problem.
>>>
>>>Do you recommend creating another set of stateful objects for the purpose
>>>of validating data and business rules, or, is there a better way?
>>>
>>>Thank you!
>>>
>>>Tony Liguori, MCSD
>>
>>
>

[D. Patrick Hoerter]

Deborah,

Don't you think field by field validation is a needless hindrance to
data entry? I do all of my validation when I post. Most data entry folks
work 'head-down' anyway, and should not be made to contend with field by
field validation, IMO. Also, this eliminates the problem that is the main
subject here. What do you think?

Regards,
D. Patrick Hoerter

Deborah Kurata wrote in message <38fdf780$1@news.devx.com>...
>One choice is to do a set of stateful objects that run on the client and
not
>under MTS.
>
>Another choice is to have a validate method in the stateless component. The
>downside of this is that the user will not get field by field validation.
>
>Good luck!
>Deborah
>
>Tony Liguori wrote in message <38fcd41d$1@news.devx.com>...
>>
>>I'm sorry to say I have not yet read your book. It's very likely that the
>>answer to my question may be found there.
>>
>>All of the 3-tiered application development that I do uses stateless
>objects
>>running in MTS. The problem is that you can't properly encapsulate the
>data
>>validation or business logic in a stateless object. For instance, you may
>>want to execute a Property Let from inside a Text1_Change event, then
>validate
>>the data from within the Property Let inside the business object. With a
>>stateful object, this was a useful technique and not a problem.
>>
>>Do you recommend creating another set of stateful objects for the purpose
>>of validating data and business rules, or, is there a better way?
>>
>>Thank you!
>>
>>Tony Liguori, MCSD
>
>