I know they used their own ORM (dapper). However, did their manually update the database for each corresponding change? Did they use a database first or a model first approach?

What I meant by manual update of the database is that there are some web developers that change their domain model during development (e.g., add an email property to the "User" class); then they add a column in the "User" table in the database to reflect this. I know that there are frameworks that handle the database changes automatically. However, since Stack Exchange software uses dapper, I was wondering how the programmers approached this in this case.

1 Answer
1

Honestly not sure if this is best on SO or MSO, but if you really want to know, our usual process would be database first:

add any new column as nullable

the db / app changes are deployed roughly at the same time, DB first; the nullable nature means that no inserts will fail in the time between DB deployment and app deployment. The time between the two will be between minutes and maybe an hour

backfill any data if needed (this could be part of the DB deployment on separate)

maybe later make it non-nullable if this is reliable

Obviously any specific scenario may require deviation from this.

The choice of ORM is unrelated here; I suspect the same approach would apply either way. As it happens we use a mix of dapper and LINQ-to-SQL. I personally find the DBML designer gets a bit messy after the fact, so I typically edit the DBML by hand rather than using the designer. This then updates the object model shared between L2S and dappper.