Yearly Archives: 2015

Do you need an ORM?

Do you need an ORM for your project given you use a relational database? And not just some lightweight like Dapper but a big one: NHibernate, Entity Framework, Hibernate? I’d like to address this question with this post.

Do you need an ORM? →

Domain-centric vs data-centric approaches to software development

In this post, I’d like to make a comparison of two approaches that prevail in the world of (mostly enterprise) software development: domain-centric and data-centric.

If you read my last post (or any other post, quite frankly), you might have noticed I personally gravitate towards the domain-centric approach. Although this article is intended to be an impartial one, keep in mind that my bias can leak out.

More on Domain-centric vs data-centric approaches →

Is SQL a good place for business logic?

<TL;DR> No, it isn’t. While SQL is a Turing-complete language and we can use it to encode any business logic we want, placing business (domain) logic into SQL leads to a less maintainable solution comparing to one that uses an OO or functional language. Because of that, I advocate to limit the use of SQL to read-only queries (which can potentially contain business logic, that’s fine) and simple CRUD statements where possible.</TL;DR>

The dispute regarding whether or not one should place business logic in SQL takes place for as long as I can remember. It’s much less active these days, but still exists, so let’s elaborate on the details here.

SQL and business logic →

Why following software design best practices decreases code complexity

Most of us agree that in many cases following best practices leads to better code. Namely, it decreases the complexity and allows us to reason about even large software systems easier.

But why is that so, exactly? Today, we’ll take two design principles – separation of concerns and immutability – and see how (and why!) they decrease the complexity of the code.

Continue reading