We have all been in the situation of having to work on heavily transactional code bases, and we have needed to use stored procedures to retrieve the data. These two usages are normally ignored in the first discussions for the code, but they can be accomplished with fairly little effort.

In code first, the usage of stored procedures is an edge case, but when we have to do it, there are pieces that we can leverage. The idea that stored procedures are a better place for holding some data-centric business logic, or using them to control the access to our database has been widely held for years. This means that we have a very high chance of needing to connect to and communicate with legacy database schemas that use stored procedures to return scalar data about the database, or even use them to populate entities.

The usage of transactions is a fundamental idea for the Entity Framework as a whole. The context that we use to communicate to the database leverages transactions internally, without any extra code from the user. This allows us to write less code, and think of the larger picture. If we do need multiple contexts or to manually extend transactions beyond the simple call to save changes, then we can take advantage of these features without much effort.