YES, your core business objects should be aware of the limitations. Aspects are not part of your business model, and don't care about rules and such (or at least they shouldn't!).
So, if you want to intercept method calls to perform validation, that's a perfectly acceptable use of AOP. The important part is the aspect itself doesn't do the validation - the aspect sees a detail item coming in, and either calls validate() on it or passes it to some validation service or rules engine or however you build your application. Programming an aspect in this manner allows you to reuse the validation/rule-enforcement business logic elsewhere in a more direct fashion. The aspect just gives you a *different* way to weave things together. Does that help? -Dave On 7/4/06, Adam Haskell <[EMAIL PROTECTED]> wrote:
This application sits outside of the POS terminal so this does not work with payments or anything of the sort. It is strictly PSE purchase tracking and reporting. Thankfully the business owners decided how to ID people; by State ID, drivers license, or Passport number. Stores are not limited to sales, customers are limited by federal and state laws, and specific transaction are limited by federal and state laws. Sounds like my original idea (a limitations object of sorts) is ok but you disagree with it being an aspect b/c you think it is appropriate for the objects to be aware of the limitations, where as by putting it in an aspect the objects are unaware of the limitations that are being imposed on them (let me know if I am reading that wrong). That's the exact type of response I was looking for, should my core objects be aware of the limitations? Sounds like you say yes they should be aware. I appreciate the response, I don't know I am entirely convince one way or the other still thinking about it, though the more I think about it I think I am leaning towards it not being an aspect. What if I threw in this. We have a similar application that tracks sales of Ashley Furniture. Without getting into too much detail the same set of core components could be used if I had the limitations through and aspect, or I probably could extended the core components to work inside the PSE application does this make any sense? Adam On 7/4/06, Peter Bell <[EMAIL PROTECTED]> wrote: > > > > Hi Adam, > > I would add this to the core business model. For me, aspects are cross cutting concerns that decrease cohesion (a product shouldn't know about logging, security or workflow, so those are the classic examples of AOP). To me it is perfectly appropriate that a business object would know about these limitations - even if you sell outside the US and this is a US only limitation, I'd still put this into the model as a "US only rule". > > As to where it should go, it would depend on the business rule. The store might know the total you can sell to all customers, a user might know they'd bought too much within a day or a cart might know that it had too much in that given cart. (BTW, good luck with the actual logic - how do you uniquely define a customer when one person could have different email addresses, shipping addresses and credit cards?!) If you needed more than one of these rules implemented, you may make a call to a seperate object that would encapsulate all of the PSE rules. I'm guessing you're also going to have to extend the product business object to include a getPSE() method (the product knows how much PSE it contains, but not how much the store, user or cart contains, so a getter for that one piece of information is appropriate). > > Of course, you also need to make sure that your cart.add() method returns the status of the add (you could also use this for people buying too much stuff for their credit line or ordering more product than you have in inventory or some other cases where cart.add() will fail) and probably an error message so you can display the cart view with "Cart not updated successfully: #ErrorMessage#"." > > Just some thoughts. > > Best Wishes, > Peter > > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Adam Haskell > Sent: Monday, July 03, 2006 5:10 PM > To: [email protected] > Subject: [CFCDev] Aspect or not? > > As some may know the lovely US gov't has put new laws in place limiting the sale of Psuedoephedrine. Right now I am in the process of reworking the original application into Model Glue framework also using Coldspring. So here is my question: > > Right now the Application merrily has transaction and transaction detail objects (among others). Each detail is added through an AJAX call to the server. My thought right now is to put the code that determines if the current detail can be added to the transaction into an aspect. The idea being that the core objects do not change and the transaction object can continue to happily append details, telling to persist ect. The aspect would "sniff" the detail and if the detail can not be saved due to legal limitation (too many grams of PSE or too many packages per day) the aspect throws an error OverLimit and the application deals with it. My concern is that by through the error I will end of having to deal with that in the transaction object thus changing it anyway. Maybe that's an OK thing but I need someone else to tell me that, or maybe some different suggestions. I just need a reality check from people that have probably been doing this more than me. > > Adam Haskell > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). > > An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com). > > An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
