When dealing with enterprise software, your data is often the most valuable part. It contains all your customer information, contracts, invoices and much more. So what are you going to do to make sure the data is being dealt with correctly? A bug in your code can have a high impact on the integrity of your data. If the bug is causing unwanted changes in your data, fixing the damage might prove to be quite a big challenge.
With this post I would like to show how data immutability can help design a more robust system. One that is less susceptible to bugs that might make unwanted changes to your data.
Recently WouterJ has written an excellent article about repositories and how to treat them as collections. In it he also shows that it is useful to have interfaces on your repository classes. If you have not yet read it, I fully recommend doing so.
This concept is something I have recently applied in a project and found that there are some extra benefits in using those interfaces. In this post I would like to expand on WouterJ's ideas and show how this enables service decoration.
A lot of developers come to
#symfony and ask how to implement a login or authentication system. It's quite common to
have a bunch of features which require authentication and authorization. While authentication is identifying your user,
authorization is granting permissions to this user.
One of the steps of implementing the security features of your application, involves creating an object to contain
your user information such as your username, email, password and user id. If you have followed the Symfony docs,
you will most likely have ended up with a
User entity implementing the
Symfony\Component\Security\Core\User\UserInterface. I would like to show you an alternative- decoupled- approach
which will prevent several issues within a Symfony application.
Being active on IRC, almost every day I see questions coming by regarding forms and entities inside. This does not only give you a headache but it's also risky. You wouldn't want to flush an entity in an invalid state!
"But Using Entities in my Forms is Easy!" Yes, it's certainly easy. You don't have to write any additional code to connect your validation rules and data mapping, not to mention that when it's valid, you only have to flush your entity and you're done. Using this method is especially easy when using CRUD and makes developing applications faster, thus RAD friendly.