views:

83

answers:

3

I have just finished reading an article on MSDN by John Evdemon. He bashes the CRUD interfaces and calls it an anti-pattern.

While I agree that having ANYTHING stateful is difficult and Current and MoveNext are bad ideas I don't agree that CRUD as in Create Read Update and Delete are bad. If I have a car service and I want to let clients be able to do the basics, as in Create a car, get a cars details, update a cars details or delete a car then how are they meant to be able to do those things without CRUD operations.

Or what am I missing here?

+2  A: 

RESTfull web services which have been lately gaining popularity are proving wrong Mr. John Evdemon's post.

Boris Pavlović
+2  A: 

I think he has on purpose designed the worst possible interface here and it is not really a CRUD interface.

_ Public Function MoveNext() As Boolean End Function

_ Public Function Current() As Object End Function

These two methods are obviously not stateless, but nor are they needed for a true CRUD interface. I think it just a very poorly written example and it is not really related to CRUD operations.

--update--

Found a similar question with a very good answer :)

willcodejavaforfood
+3  A: 

The CRUD interfaces should be avoided in distributed system / SOA scenario because they are very chatty. But should doesn't mean have to. When you have some client actions which require more than one call to your service then you know that you should give up CRUD approach and create new service operation which will agregate those calls into single call. When designing distributed system you should always reduce number of calls to minimum because network call is very time consuming.

Edit:

You can think about CRUD interface as about data access exposed in a service. Sometimes you really want this. But in SOA and distributed system architecture you are usually exposing business functionality which already wraps data access and offers much more complex operations (which agregate many data access operations).

Example:

CRUD x Business logic intefrace. Suppose that you are working with Invoices. Each invoice consits of InvoiceHeader and one or more InvoiceLine. If you use CRUD interface for invoice you will first call CreateInvoiceHeader operation to create InvoiceHeader and then several AddInvoiceLine operations to add all InvoiceLines - that is low level CRUD approach. But if you implement business logic on the service side you will call single CreateInvoice and pass complex object graph (header with all lines) to the service to create and add what is needed. Create method can also do other business operations like starting some workflow etc. That is common SOA and distributed system approach.

Ladislav Mrnka
@Ladislav. That confuses me a bit. How do we let clients create new entities or update their details if we don't expose CRUD operations. For example Just a simple Create method that accepts a car. If there is a problem then we send back the fault. If you get nothing then it was successful. In my mind it can't get less chatty. Like I said I might be missing something big here.
uriDium
@uriDium: I added some example.
Ladislav Mrnka
@Ladislav: Oh right. Thanks for the example. So CRUD in almost a "true form" where everything gets decomposed to basic Create Read Update or Delete is a bad idea because it forces chatty services. If you can wrap them all up in a single service method like for instance PlaceOrder(invoiceHeader, List<InvoiceLines>) would be much better because it cuts down on the chat and makes more business sense. But there is obviously still a case where we might just need to create a single object. Am I getting the idea?
uriDium
@uriDium: Yes. But this was simple example. You can imagine much more complex or you can find another example where for example Update will need whole entity but client will post only simple value and service's business logic will be responsible for setting others.
Ladislav Mrnka