I’ve been on a bit of kick lately, rethinking how I build applications, particularly with the aim of reducing complexity. One thing that has been readily apparent (even in the bad old days when we called it service oriented architecture) is how breaking a system into small, discrete pieces that do a single thing well makes it much easier to maintain and reason about code. This approach works really well for scaling, deployment, and for quickly being able to build out a piece of functionality without entangling it with other systems. The model works really well for the way I typically think about code in general these days. Breaking the system into smaller pieces also allows me to optimize my technology choices for the problem I’m trying to solve at a much more granular level, which often makes things simpler (in practice, I still typically stick with just c# code, but the ability to throw node, ruby, or python into the mix can be handy at times).

Object-relational mappers (hereafter called ORMs) are used to provide a way for one to map an object in an object-oriented language to a table or set of tables in a (usually) relational database. On the Microsoft stack, they’ve become so popular as to be nearly ubiquitous. They do have their detractors, including people that have developed their own, such as Rob Conery, who developed TWO ORMs (Massive and Subsonic). That said, they do often make the earlier phases of a project much easier, by allowing developers to abstract away the pain of relational data access. This is frequently helpful in the early phases of a project because developers are moving quickly and breaking things while trying to quickly iterate over a design. That said, I find that the way ORMs are frequently used is often rather unhelpful as a project matures (and possibly rather unhelpful in the early phases as well).