If the user has any books that are overdue, they are not allowed to borrow any new books until they have returned the overdue book(s). Each book is allowed to be borrowed for a set amount of time (1 week, rounded to the nearest day). A user is allowed to borrow up to 3 books at a time. Our client is a library (with books in it link is to Wikipedia for those unfamiliar with the concepts.) Our application tracks users who borrow and return books. Here's the situation we're going to be coding against. Let's start with an example, because I like talking about actual code instead of waving my hands around and talking theory. Just put a bunch of DBAs into a room, ask them if we should be storing calculated or derived data in the database, and duck for cover. There's still problems here and I'll call them out, but we'll be wading into treacherous waters. Interact with the database after you call the rules to persist your results. Interact with the database before you call the rules to get your data and pass it into working memory. But luckily there's a general rule of thumb which is this: It depends on what your rules are actually doing and your problem space. The answer you've all been waiting for is. Now, in part 3, I finally get around to explaining what you should do instead. A well-design data abstraction layer would mean that we don't need to worry about things like connection pooling and transaction management, so in theory we could just interact with the DAOs and we'd be fine, right? Technically, yes, you could - but the danger here becomes that you need to have extensive knowledge of how the Drools lifecycle works, along with how your data models are coupled (especially if you use hibernate's lazy loading.) This creates a significant issue for future maintenance, since it's not possible to test for the problems that you might introduce due to lack of knowledge in these areas - such as data inconsistency arising from race conditions. In part 2, I talked about why even interacting with DAOs should be avoided. I'm not even sure it's possible to attempt in any sane fashion in a decision table. It's just about impossible to properly manage transactions, connections (with or without pooling), prepared statements, result sets, and so on within the confines of a DRL file. In part 1, I explained why you shouldn't try to interact with the database directly from your rules (DRL or otherwise.) Safely interacting with a database using a JDBC driver (or library) is incredibly involved and takes significant effort to do safely and properly, especially in a production environment. One of the most common questions on StackOverflow in the Drools tag is something along the lines of "how do I call my database from my rules?"
If you don't want to spend half your day reading, I'll summarize the salient points here.
0 kommentar(er)
