Why Is CRUD a Bad Idea Focus on Real Scenarios
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Why Is CRUD a Bad IdeaFocus on Real Scenarios
Petr HeinzMore than 8 years of programming experience.
Loves clean code, regular expressions and clever design.
Dedicated last year to developing the Shopsys Framework, open source e-commerce framework made with passion on Symfony 3.
Typical CRUD
Create, Read, Update and DeleteFour basic functions of an persistent storage, often used as an API.
Can be mapped to SQL statements:
INSERT SELECT UPDATE DELETE
Can be mapped to HTTP methods (used in REST APIs):
PUT GET POST DELETE
Example: Articleclass Article {
private $author, $text, $state, $published;
public function setAuthor(Author $author) { $this->author = $author; }
public function getAuthor() { return $this->author; }
public function setText($text) { $this->text = $text; }
// ...
}
class ArticleController {
public function create(...) { // ... }
public function update(...) { // ...
$article->setAuthor($author); $article->setText($text); $article->setState($state); $article->setPublished($published); }
public function delete(...) { // ... }
}
Entities Must Follow Business RulesEntities are often constrained by business rules and the consistency must be kept.
● Company customer must have VAT ID filled in his account.
● Sold out product must be hidden.
● Article in published state must have published date.
This is difficult to achieve in the previous example. That’s because all article
attributes can be changed independently. Developers are not restricted in the way
they interact with the object.
Example: Article without settersclass Article {
const STATE_UNPUBLISHED = 1; const STATE_PUBLISHED = 2; const STATE_DELETED = 3;
private $author, $text, $state, $published;
public function __construct(Author $author, $text, $state, DateTime $published = null) { // ... }
public function update(Author $author, $text, $state, DateTime $published = null) { // ... }
public function delete() { $this->state = self::STATE_DELETED; }
}
Example: Article without settersclass Article {
// ...
public function update(Author $author, $text, $state, DateTime $published = null) { if ($this->state === self::STATE_DELETED) { throw new ArticleIsDeletedException($this); }
$this->author = $author; $this->text = $text; $this->state = $state;
if ($state === self::STATE_PUBLISHED) { $this->published = $published ?: new DateTime(); } elseif ($state === self::STATE_UNPUBLISHED) { $this->published = null; } }
}
What Is an Object Anyway?
Object Oriented ProgrammingObjects have both data (their properties) and behavior (their methods).
Objects model real-world behavior, concepts and relationships.
Encapsulation principle tells us to hide the details about the data and focus solely
on the behavior - the public methods of our objects (“Tell, Don’t Ask”).
In PHP it is easy to combine procedural and object-oriented programming.
Example: Bank Account Objectclass BankAccount {
private $balance;
public function __construct(Money $balance) { $this->balance = $balance; }
public function deposit(Money $amount) { $this->balance = $this->balance->add($amount); }
public function withdraw(Money $amount) { if ($this->balance->isLessThan($amount)) { throw new InsufficientFundsException($balance, $amount); } $this->balance = $this->balance->subtract($amount); }
}
Anemic / Rich Domain Model
Let’s Define Some Terms FirstDomain: Most common definition: “A sphere of knowledge or activity.”
It’s basically the subject area of your application (eg. an online store or news site).
Domain Model: System of abstractions describing part of the domain that can be
used to solve problems. Simplification of the real world.
Domain Object: Object that is part of the domain model (eg. Product, Order, …).
Business Logic: High-level logic reflecting the real-world business rules.
Anemic Domain ModelNo business logic in domain objects
Clearly separates logic and data
Violates object encapsulation
Works well for simple applications
Leads to procedural programming
Called an anti-pattern by M. Fowler
Business logic mainly in domain objects
Domain objects encapsulate inner data,
offer meaningful behavior
Data integrity kept by the encapsulation
Better choice for complex domain
models
Rich Domain Model
Anemic Domain Model Rich Domain Modelclass Worker {
function getVelocity() { return $this->velocity; }
function setVelocity($velocity) { $this->velocity = $velocity; }
}
class WorkerService {
function work(Worker $w, Task $t, $time) { $progress = $t->getProgress(); $progress += $w->getVelocity() * $time; $t->setProgress($progress); }
}
class Worker {
function __construct($velocity) { $this->velocity = $velocity; }
function work(Task $task, $time) { $progress = $this->velocity * $time; $task->makeProgress($progress); }
}
The Problem Lies in Setters
Setters Do Not Exist in the Real WorldSetters have no meaning in the real world:
● A writer does not set a “published” state to an article, he/she publishes it.
● Customers do not set a “paid” status to an order, they pay for it.
● Your happy boss does not set a higher salary to you, he/she raises it.
There is always a better, more expressive, alternative to a setter.
Expressive statements lead to more readable code.
Nobody Expects The Setters To Do StuffSimilarly to adding logic to a CRUD
update, you might feel the need to add
some business logic to your setter.
The problem with this is that nobody
expects setters to do anything beside
setting the property.
An unexpected behavior leads to bugs.
class Order {
// ...
public function setStatus($status) { if (!$this->isValidStatus($status)) { throw new InvalidArgumentException(); }
$this->status = $status;
if ($status === self::STATUS_PAID) { $this->mailService->sendOrderPaidMail( $this->orderNumber, $this->customer ); } }
}
Nobody Expects The Setters To Do StuffSimilarly to adding logic to a CRUD
update, you might feel the need to add
some business logic to your setter.
The problem with this is that nobody
expects setters to do anything beside
setting the property.
An unexpected behavior leads to bugs.
class Order {
// ...
public function pay() { $this->status = self::STATUS_PAID;
$this->mailService->sendOrderPaidMail( $this->orderNumber, $this->customer ); }
public function cancel() { $this->status = self::STATUS_CANCELLED; }
}
An Update in CRUD Is Similar to a SetterGeneric update method in CRUD is similar to a setter:
● It does not have a real-world meaning.
● There are better alternatives based on real scenarios to be implemented.
For example, by “updating” an article we mean “rewriting” it and possibly
“publishing”, “unpublishing” or “deleting” it.
Conclusion and Recommendations
Focus on Real ScenariosBy building your application around you domain objects and their behavior you
can get expressive code that is easier to understand, use and maintain.
Concept of “setting” or “updating” to too generic to be meaningful.
Your API should be focused on real scenarios, real use-cases. This will keep the
API clean and intuitive and it will help you keep the integrity of your data.
Think About the Way You ProgramThere is no best way, no silver bullet. And there probably never will be one.
Keep in mind the techniques of object-oriented programming, encapsulation
principle, focusing on the behavior.
Knowing about the two extremes will help you improve the design of your
application and choose the proper solution for your project.
Need CRUD methods? Add a Layer.If you for some reason want to
allow classical CRUD methods,
you can build it on top of your
internal API.
You can use Adapter pattern for
this task.
class Article {
// ...
public function update(...) { if ($this->state === self::STATE_DELETED) { throw new ArticleIsDeletedEx($this); }
$this->author = $author; $this->text = $text; $this->state = $state;
if ($state === self::STATE_PUBLISHED) { $this->published = $published ?: new DateTime(); } elseif ($state === self::STATE_UNPUBLISHED) { $this->published = null; } }
}
Need CRUD methods? Add a Layer.If you for some reason want to
allow classical CRUD methods,
you can build it on top of your
internal API.
You can use Adapter pattern for
this task.
class ArticleCrudAdapter {
// ...
public function update(...) { if ($this->article->isDeleted()) { throw new ArticleIsDeletedEx($this->article); }
$this->article->rewrite($text, $author); switch ($state) { case Article::STATE_PUBLISHED: $this->article->publish($published); break; case Article::STATE_UNPUBLISHED: $this->article->unpublish(); break; case Article::STATE_DELETED: $this->article->delete(); break; } }
}
It Is About the BalanceEvery way has its tradeoffs and, as always, it is about the balance.
Focusing on real-world use-cases helps to maintain integrity and usability.
Integration with other libraries or components is easier with generic methods.
When developing Shopsys Framework we try to keep that in mind, and take
inspiration from Rich Domain Model.
See for yourself, join closed beta: https://www.shopsys-framework.com
Thanks for listening!
Let’s get down to your questions!
Related Documents
