Re: [cf-orm-dev] Frameworks, validation and ORM transactionality
Bob Silverberg
everything. You could avoid issues of having to worry about Hibernate
by using a DTO, but I don't like to have to introduce another
object/layer for that.
Also, regarding your question of transactions in controllers, I always
do all of this in the service layer, so the controller is entirely out
of the picture.
I think the safest solution is to wrap everything in a txn and then
rollback the txn if validation fails. I have had people disagree with
that approach vehemently, but I still think it is a viable approach in
many situations.
Another approach is to populate the object outside of a txn, and then
only start a txn if the object is valid. With this approach you also
must use settings that will only allow an object to be persisted
within a txn (flushatrequestend=false, automanagesession=false), and
you must ensure that no txns will commit later in your request (e.g.,
for logging purposes). If you are in control of all persistence
operations and stay aware of the fact that you could have an invalid
object in a hibernate session at any time, then you can architect your
system in this way.
It is all of those "ifs" and "musts" that make me feel like the
rollback solution is simpler and safer.
A third option would be to clear the hibernate session after
validation failure, which is also simpler than option #2, but you
still need to be aware of what is going on in the session to make sure
you don't clear something that you didn't mean to.
So I guess the bottom line to me is that there is not one "right" way
to do it, but there are a number of options which depend on your
overall system requirements.
Cheers,
Bob
On Tue, Jan 3, 2012 at 9:27 AM, Tom McNeer <tmc...@gmail.com> wrote:
> Hi,
>
> I'm sure this has been discussed or blogged about extensively before, but
> though I've done lots of searches, I'm coming up empty. If someone wishes to
> point me to a reference, please do.
>
> I have used ORM in only one application so far; I am about to start two
> more. And what I'm looking for is clarity (and/or best practices) on a very
> common scenario that I just can't quite wrap my head around.
>
> Let's assume the application in question is a typical HTML application. It
> uses a CF MVC framework of one kind or another. It also uses a DI framework.
> And a validation framework.
>
> We have a data entry form, with fields that match properties of an ORM
> Entity. Let's say that the field names match the property names. When the
> form is submitted and the request is handled by a controller, there is a
> populate() method available somewhere which can set the form field values
> into an object.
>
> And let's say that we're using ValidateThis to handle the validation.
>
> So it's the usual: we want to auto-populate an object, validate its
> properties, send it to a service for persisting if it is valid, avoid saving
> it if it is invalid.
>
> Where should the actual ORM Entity come into play here?
>
> Is it best to only use the Entity within the service layer, passing a DTO
> back and forth from the controller, and populating the DTO from the Entity
> and vice versa only within the service?
>
> Is it practical to use the Entity in the controller and validation? If the
> populate() method sets properties into the Entity, isn't there a chance that
> Hibernate will choose to save the Entity at some point, even if a property
> is invalid (if, for example, an e-mail address fails validation)? Does the
> validation have to be wrapped in a transaction so that this doesn't happen?
> (Doesn't seem like there should be transactions in a controller.)
>
> Perhaps I'm missing something simple (such as a blog entry that explains
> this). But I'm still hazy on how to handle this aspect of an application.
>
> What's the best/simplest way to approach this? Or at least, how are others
> doing so?
>
> Thanks in advance for helping to clear up my haziness.
>
>
> --
> Thanks,
>
> Tom
>
> Tom McNeer
> MediumCool
> http://www.mediumcool.com
> 1735 Johnson Road NE
> Atlanta, GA 30306
> 404.589.0560
>
> --
> You received this message because you are subscribed to the Google Groups
> "cf-orm-dev" group.
> To post to this group, send email to cf-or...@googlegroups.com.
> To unsubscribe from this group, send email to
> cf-orm-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/cf-orm-dev?hl=en.
--
Bob Silverberg
www.silverwareconsulting.com
Tom McNeer
Thanks for the quick reply. I was hoping you might step in, since, well, you know a bit about handling the validation process.
I understand most of what what you're saying. I'd just like to ask a couple of quick questions:
Also, regarding your question of transactions in controllers, I always
do all of this in the service layer, so the controller is entirely out
of the picture.
So are you saying your validation is handled within the service layer, rather than the controller layer? Are your form field values passed back into the service directly, rather than populating some object in the controller?
I think the safest solution is to wrap everything in a txn and then
rollback the txn if validation fails. I have had people disagree with
that approach vehemently, but I still think it is a viable approach in
many situations.
I think I've missed those disagreements. What was their primary reason for the vehemence?
So I guess the bottom line to me is that there is not one "right" way
to do it, but there are a number of options which depend on your
overall system requirements.
Thanks. I was pretty certain there wasn't a "right" way. But I figured that you and some other folks who've explored this area extensively would have good advice.
Bob Silverberg
> Hi Bob,
>
> Thanks for the quick reply. I was hoping you might step in, since, well, you
> know a bit about handling the validation process.
>
> I understand most of what what you're saying. I'd just like to ask a couple
> of quick questions:
>
> On Tue, Jan 3, 2012 at 9:42 AM, Bob Silverberg <bob.sil...@gmail.com>
> wrote:
>>
>> Also, regarding your question of transactions in controllers, I always
>> do all of this in the service layer, so the controller is entirely out
>> of the picture.
>
>
> So are you saying your validation is handled within the service layer,
> rather than the controller layer? Are your form field values passed back
> into the service directly, rather than populating some object in the
> controller?
>
Exactly. I pass the form struct into the service layer method. Or, if
I'm using an MVC framework I use it to pass a struct from its event
object into the service layer method.
>>
>>
>> I think the safest solution is to wrap everything in a txn and then
>> rollback the txn if validation fails. I have had people disagree with
>> that approach vehemently, but I still think it is a viable approach in
>> many situations.
>
>
> I think I've missed those disagreements. What was their primary reason for
> the vehemence?
>
The reason: "That's not what transactions are for. A rollback isn't
intended as an integral part of application logic, it's intended to
address unforeseen exceptions." I am paraphrasing here, but that was
the gist of it. Rollbacks can be expensive too, which is one of the
reasons the system you are designing is a factor. If it isn't going to
be a particularly demanding system, and scaling isn't an issue, then
the performance penalty might be insignificant.
>
>> So I guess the bottom line to me is that there is not one "right" way
>> to do it, but there are a number of options which depend on your
>> overall system requirements.
>
>
> Thanks. I was pretty certain there wasn't a "right" way. But I figured that
> you and some other folks who've explored this area extensively would have
> good advice.
>
>
> --
> Thanks,
>
> Tom
>
> Tom McNeer
> MediumCool
> http://www.mediumcool.com
> 1735 Johnson Road NE
> Atlanta, GA 30306
> 404.589.0560
>
--
Bob Silverberg
www.silverwareconsulting.com
Tom McNeer
Thanks very much for the advice.
Bob, thank you for the further explanation. I understand the issue with the cost (and purpose) of using a rollback. So the decision is part philosophical/part performance.
John, thanks for adding your voice. The reason I mentioned the use of a DTO is that I recently worked on an application where the use of DTOs outside the service layer was part of the specification. In that application, form variables populated the DTOs in the controller, and those objects were passed to ValidateThis by the controller before the DTO was passed back to the service layer for persistence. Just another way to do it.
And thanks for writing a great book, by the way! Maybe this issue is something to address in the second edition!
Bob Silverberg
> Bob, John,
>
> Thanks very much for the advice.
>
> Bob, thank you for the further explanation. I understand the issue with the
> cost (and purpose) of using a rollback. So the decision is part
> philosophical/part performance.
>
> John, thanks for adding your voice. The reason I mentioned the use of a DTO
> is that I recently worked on an application where the use of DTOs outside
> the service layer was part of the specification. In that application, form
> variables populated the DTOs in the controller, and those objects were
> passed to ValidateThis by the controller before the DTO was passed back to
> the service layer for persistence. Just another way to do it.
>
I agree that using a DTO does address the problem and is perhaps the
best decision purely from a design perspective, but from a practical
perspective I just plain don't like having to worry about an extra set
of objects.
I'm glad to hear that VT was part of your stack though, it's always
nice to hear about people actually using it. :-)
Cheers,
Bob
> And thanks for writing a great book, by the way! Maybe this issue is
> something to address in the second edition!
>
>
>
>
> --
> Thanks,
>
> Tom
>
> Tom McNeer
> MediumCool
> http://www.mediumcool.com
> 1735 Johnson Road NE
> Atlanta, GA 30306
> 404.589.0560
>
> --
> You received this message because you are subscribed to the Google Groups
> "ValidateThis" group.
> To post to this group, send email to valida...@googlegroups.com.
> To unsubscribe from this group, send email to
> validatethis...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/validatethis?hl=en.
--
Bob Silverberg
www.silverwareconsulting.com