I agree with you and pretty much came to the same conclusion. My issue is that I'm dealing in more of an SOA world so leaving validation to a web tier validator means that I have to duplicate validation in the service which is not good. When dealing with services you need to bear in mind that you don't know what type of client is going to access the service so it has to be a self contained unit. So it has to be able to do that mandatory checking type of stuff. The way I've done it now, since I'm using EJB3 is to use the entity beans as the dto's and pass them in to the service, do the validation/business rules on them and build a collection of error objects into the entity bean pojo to be returned to the client. Those errors can be stripped out and dealt with by whatever client is using them. This has a number of advantages: 1. All my business rules are in the one place. 2. The web tier is very lightweight. 3. The session beans are very lightweight as they are strictly concerned with persistence and not logic. 4. Put some WSDL on the front and have .Net, J2EE, Delphi access it and it all behaves the same way.
On 1/31/06, Matthew Shaw <[EMAIL PROTECTED]> wrote: > > Hi Paul, > > in what framework are you using drools? I am using a struts plugin validator > which accesses a set of validation rules stored in my drl. This works very > nicely as it leaves the grunt work to the struts validator, ie. collecting > the errors and displaying them appropriately. > > Traditionally drools has been a means to representing the business logic of > your application, but the distinguishment between business and validation has > always been a touchy one. This is where you have to draw your own line. What > are those exceptions that should stop application execution, versus those > which are user entry problems? > > I went down the track at one stage of trying to do the same thing you are. > Getting my rule engine to throw an exception. But the problem was that the > rule engine in my app is fronted by business delegate and session facade > patterns. As I am using the j2ee framework with struts, I was bypassing the > struts validation and going through the business and then trying to > revalidate again. Which is wrong and as I found out, causes no end of > problems and an unwarranted tutorial of struts! :) > > Regards, > Matt. > > -----Original Message----- > From: Paul Smith [mailto:[EMAIL PROTECTED] > Sent: Monday, 30 January 2006 2:36 PM > To: [email protected] > Subject: [drools-user] Stragegies for stacking Exceptions > > > Hi All, > > I maybe missing something fairly basic here but what I'm trying to do > is have some of my rules throw an exception when the condition is true > but I want to be able to stack those exceptions and return them all to > be iterated through. Currently I only get one exception back which > will basically be whichever rule is fired first. The only way I can > think of doing this is instead of throwing the exception, add it to a > list in the application data, then when I return from the rules > engine, get that list from the application data and throw it back to > the client. The example scenario is as follows: > > I want to be able to validate say an address but have each validation > failure point as an exception and the list of exception messages then > displayed to the client. eg) The user didn't set the postcode and the > street number. The two validation exceptions are "Must enter a > postcode" and "Must enter a street address". Each validation rule > throws a ValidationException with a key and a message. > > Is this the way to do it or not? > > Regards > > Paul > > This correspondence is for the named persons only. > It may contain confidential or privileged information or both. > No confidentiality or privilege is waived or lost by any mis transmission. > If you receive this correspondence in error please delete it from your system > immediately and notify the sender. > You must not disclose, copy or relay on any part of this correspondence, if > you are not the intended recipient. > Any opinions expressed in this message are those of the individual sender > except where the sender expressly, > and with the authority, states them to be the opinions of the Department of > Emergency Services, Queensland. >
