1

Let's say I have an application that is 80% complex business logic and 20% CRUD, or vice versa.

In the past I have used some kind of command pattern and had classes like ComplexFooCMD or EvenMoreComplexBarCMD but always ended up with a bunch of InsertFoo, UpdateFoo, DeleteFoo and SelectFoosCMD and a few of UpdateSomeValuesOfFoo or SelectSomeFoos. All of these lived in the BLL.

Recently on less complex business logic applications I have used a service pattern with classes like FooService but these also contain the expected insertFoo, updateFoo and selectSomeFoo. Having these methods on every service or even having services which only exist to expose those methods to the presentation layer feels like a lot of boiler plate code.

Is there any pattern that fits both the CRUD part and the rest of the application, or should I use different patterns for the different parts of the application?

APC
  • 144,005
  • 19
  • 170
  • 281
RRoman
  • 741
  • 9
  • 19

2 Answers2

0

I wouldn't consider CRUD to be business rules.

I'm not sure there's a pattern for rules like "give preferred customers a percentage discount that's a function of their volume of sales to date for the year" or "don't display this option in the user interface for clients whose corporate address is from this list of states".

Business rules are not always so neat.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • well, most of the time i have CRUD rules like "when inserting a foo, also insert a bar with foo's id " such rules can be implemented directly on the db but db admins don't like much that. – RRoman Dec 30 '10 at 02:44
  • Something like that belongs inside a service layer that knows the use case, not in the persistence tier itself. CRUD operations should only encapsulate the mechanics of how to persist an object, not when to do it. – duffymo Dec 30 '10 at 02:52
0

I would strongly recommend reading up on behavior-driven development. I think it will guide you in the right direction.

The best book I've read on the subject is The RSpec Book but if you're going to be put off by a lot of Ruby-centric examples, you may want to look at other resources based in your favourite language.

In short, the answer to your question is: let your tests guide your architecture and let your app's required behavior guide your tests.

pdr
  • 6,372
  • 1
  • 29
  • 38