3

I have an application that handles licence registrations for various product. I'm currently re-factoring into a basic MVC framework (not using any of the big ones yet). We have various basic scenario's e.g. someone can make a cc purchase of a product via the website. This fires the create customer, create order, create licence etc objects (basically just db inserts using beans and gateways as I think that is the "standard"?).

Anyway, to handle all this I'm calling a purchaseService.cfc, which validates the various business rules and wraps the persistence(db) layer processes together. That seems to work fine and I thought having a purchaseService cfc contained that process well.

Now we need another, similar process where a key can be "registered" to achieve the same as above. i.e. provide a licence to the customer. (obviously there will be differing rules).

As far as naming conventions go, are there any rules to help decide what to call these service "wrapper" type cfc's. Most of the examples I see are per object, e.g. the user object has a userGateway and userService and don't give examples of cases where we need a wrapper to call multiple objects. Is what I've done ok convention wise using a purchaseService object? (I was going to call it CustomerlicenceOrder.cfc based on the other objects it was dependent on. What will I do with the new requirement? Perhaps create another service object? Called PurchaseByKeyService? Doesn't sound right to me. I have read so much on OO and MVC etc etc but the more I read the more questions I have :)

Thanks

heartygooner
  • 43
  • 1
  • 4

1 Answers1

1

There's certainly nothing wrong with grouping actions into a common service. In fact, it's usually more accepted than just creating standalone services for each domain object.

Read more on the Service Layer pattern if you're interested.

Todd Sharp
  • 3,207
  • 2
  • 19
  • 27