Hi Dave, Interesting. I'd always though of AOP as primarily a tool for increasing cohesion and DRY by pulling out cross cutting concerns. What you're suggesting is that it is also an appropriate way of effectively dropping a publish/subscribe pattern inside your business model where you could look at all method calls as published events and point cuts subscribing an aspect to matching method calls.
Firstly, do you think this is a good way to go or just a "fix"? If it is a "good" way to go, how far would you take it? Would you look at this as a model for implementing variability across applications by putting everything that varies (e.g. shipping rules, tax rules, checkout rules, etc.) into aspects and just using a different set of aspects to customize one application from another? It is an intriguing approach. I'm a little concerned about the loss of readability that you always get with this kind of implicit invocation, but am fascinated with the possibilitites of another approach to encapsulating variability between applications . . . Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Ross Sent: Wednesday, July 05, 2006 12:22 PM To: [email protected] Subject: Re: [CFCDev] Aspect or not? 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] ---------------------------------------------------------- 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]
