CRUD Interface for a Service - Is a bad practice ?

I have been reading in different places that using a CRUD (Create, Read, Update, Delete) interface for a service is considered a bad practice or anti-pattern. Therefore, this kind of interface should be avoided at all cost.

I am not agree with this at all, when I hear the word CRUD, I assume something like this:

  • CreateCustomer (Create new customer)
  • ModifyCustomer (Modify an existing customer)
  • DeleteCustomer (Delete an existing customer)
  • FindCustomer (Find an existing customer)

This is typical case of a CRUD interface to manage data related to a customer entity.

What happens if those services represent real business events in the system that I am trying to model, and the design of them also adheres to the four tenets of service orientation, is that considered a bad practice as well ?.

I do not think so.

The sample given in this article "Principles of Service Design: Service Patterns and Anti-Patterns"  shows an ugly sample of CRUD interface, and it is ok to consider it an anti-pattern. However, not all the CRUD interfaces are modeled in that way, in fact, I have never seen such a bad design as the one shown in that sample.

What do think ?. I would like to hear any opinion about this topic.

4 Comments

  • I would have to agree, he is giving crud a bad name ;)

    In the CRUDy interface he describes, 4 out of the 5 methods are not really part of Create/Read/Update/Delete; the problem is not the CRUD, its the overall design.

  • I agree, CRUD gets a bad wrap. Services not using CRUD can be equally bad given a horrendous design. If you have a design that is solid and happens to look CRUDy, who cares? Perhaps the business needs require CRUD? After all, what systems in existence today don't need something that provides CRUD operations?

  • I agree with Robert about operations mapping to units of work. Sometimes these units are simple and therefore map cleanly to CRUD operations. But I prefer to use businessy names for the CRUD operations where possible, so instead of CreateOrder, it might be PlaceOrder. Instead of DeleteOrder, it would be CancelOrder.

    These seemingly minor wordsmithing differences (similar to Behavior Driven Development replacing "test" with "behavior") are part of a larger shift in perspective away from the shared database integration style and more towards the message-based business contract style. It's too easy to literally interpret CRUD intefaces as the new "servicey" protocol for tunneling data row synchronization between systems.

    I'm curious how RESTafarians weigh in on this subject.

  • While I agree that John's sample is a bad choice, I still dont think a CRUD makes a good interface for a good (business) service. This may make good case of composite services but a "good", well-defined, discoverable service that is useful for business, SO-like consumption should look like this
    1) DischargePatient, which is then made up of
    --- DeletePatientFromHospitalStay
    --- CreateBedManagementRecord
    --- ModifyPatientBill
    --- or something to that effect...

    It is important to note that the sub-services may not be talking WS-* and it shouldnt be if its too chatty. Of course, I am being generalistic here. What happens if the owners of the sub-services are owned by different owners within the same entitiy and have a firewall between them ?

    My point is that, I think John's message is that useful, exposed services should be as granular and business-like as possible because in essence - CreateCustomer is ONLY one small part of an entire business process and it is usually not an end to itself.

    I hope I am making some sense here. :)

Comments have been disabled for this content.