On Thu, June 8, 2006 3:07 pm, Michael Jouravlev wrote: > So your argument is basically that database roundtrips will degrade > performance.
Yes, but that's only one aspect of it... scalability is also a factor, as is number of breakage point, as is cost, because to overcome the first two you have to spend more. Not to mention complexity, and the need to hire people with more database expertise. > This should not (ideally) bother an application > developer. A framework should care about that. As far as who provides the actual code, I agree. But certainly the application developer has to worry about how the architecture affects performance, scalability, stability, etc, whether they write the code themselves or not. > If > database has already defined the rules, they should be used. But can you even code all the complex business logic in the database that you might require? I suppose you could write stored procs in Java... I wonder how much more difficult that would prove than business classes on the app server? (I've never done it, so I don't know) > But I > don't want to repeat the same rules again and again. This part we definitely agree on. But a Craig pointed out, there are different kinds of validation rules, and the repetition is limited somewhat by the domains being different. What I mean is, you want to create a new Student record in the database... you may want to validate that the first name, last name and teacher's name are entered. You do that in the presentation (whether on the client or server, doesn't matter) because they aren't "business rules" per se. You can do this and not duplicate the code (use Commons Validator, can be called via AJAX if you want, I've done it). Now, when you save the record, the record is to be tied to the teacher's record. So, now you have a referential integrity check: does the entered teacher's name exist? This isn't a check you would generally do in the presentation layer anyway, they are really two separate concerns, and appropriate in different places, so there's no real duplication there. To summarize my thinking, I think there's really three different types of validation: presentation, business and data model. The presentation-type validations are where you many times see duplication... i.e., Javascript to see if a first name is filled in, then that same check done on the server, since that double-checking is of course a best practice. I think there are ways to avoid that though: doing those validations with Commons Validator and calling it via AJAX, and still letting those SAME RULES fire when the final form is submitted, does the trick (or letting Struts generate the client-side validation code, if you want to avoid the AJAX call). For business rules, these are the "is the entered dollar amount greater than the max value for this client?" sort of validations. I find these to be more appropriate on the app server, NOT in the database, for a variety of reasons (all the reasons I mentioned earlier, plus the fact that many times you find that you want a chain of such validations, which I think is easier to build outside the database using a real CoR implementation). Then you have the database validations, things like referential integrity. In other words, only do validations here that couldn't be done previously without hitting the database. This also simplifies the data tier because it tends to reduce the number of stored procs (read: code in the database) that has to be written... most of this can be done with triggers and such, which aren't really code, not as much as stored procs anyway. In other words, I view the database as a database and not an app server, generally-speaking. > Unless I use several databases or design a > clustered system, I am not tempted to use EJBs at all. I've historically HATED EJBs for various reasons... I think EJB3 finally begins to get them right, and I think you may be surprised how and where you want to use them all of a sudden. Another discussion for another day though :) > Check out Stripes, great stuff. Yes, it's on my "take a look at that" list already :) Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
