DEV Community: jpeg729

How to mock the db in EFCore

jpeg729 — Sun, 19 Nov 2023 08:37:39 +0000

There are several options. In this article we will list the options we know of and any crazy ideas we might have.

Desirata

We want the application code to use EntityFramework as if nothing had changed.
The "database" must be seeded with some initial data, and if possible, any views and stored procedures.
The "database" should behave "similarly" to the production database.
We must be able to query this database in the tests in order to verify the results.
It may be nice to have EntityFramework tell us what it has saved to the database, instead of having to query the db.
The tests using this database must setup and teardown fast, otherwise they won't run fast.

Options

EntityFramework's InMemory provider (not recommended)

Even Microsoft's documentation say this is not recommended.

SQLite

EntityFramework has great support for SQLite and any required modifications to EntityFramework's model can be applied in the test project.

If you have an existing .db file, you can copy it for each test, or maybe even open the original file in one connection, then for each test, open a new db in memory and copy the db from the file connection into the new memory db. That might be a touch faster.

Disadvantage: This isn't the database technology used in production.

TestContainers

TestContainers can be used to create a docker container per-test, so you can use a real SQL database.

Disadvantage: This is probably slower.

LocalDb

If the production db is SQL Server, then we could use LocalDb for testing. LocalDb is a version of SQL Server that runs in the user's session. It comes with Visual Studio, but can be installed independently.

LocalDb can be used to open a .mdf file directly, and we can make a copy for each test.

This should be faster than TestContainers, and may compare favourably to sqlite.

Disadvantage: It requires LocalDb to be installed. So maybe we need to use TestContainers at least for test run on CI.

Conclusion

This article is about collecting ideas, and may be updated later.

Exploring testing AspNet web applications

jpeg729 — Tue, 17 Oct 2023 08:38:28 +0000

Introduction

Testing lies at the heart of ensuring the functionality, reliability, and security of any software application, and ASP.NET web applications are no exception. In this series of articles, we delve into the intricate world of testing ASP.NET web applications using C#. From unit tests that scrutinize individual components to end-to-end tests ensuring the seamless operation of the entire application, we explore various testing approaches and methodologies.

Understanding the Goal

Imagine you have an ASP.NET web application, and you're faced with the challenge of testing it comprehensively. How do you ensure its logic is flawless, its data remains coherent, and its user interactions are seamless? This series aims to answer these questions and more, providing insights into different aspects of testing, including:

Automated Tests at Different Scales: We'll discuss unit tests, integration tests, and end-to-end tests. Each type has its unique purpose, allowing us to validate different layers of our application's functionality.

Testing Code with External Dependencies: Real-world applications often rely on external services and databases. We'll explore strategies to test code that interacts with these dependencies, ensuring our tests remain robust and independent.

Manual Testing: While automated tests are invaluable, some scenarios require the human touch. We'll explore when and how manual testing fits into the overall testing strategy.

Setting the Context: The Application

In the articles to follow, our focus will be on testing the application logic and database access of an ASP.NET web application. This application comprises:

An interactive website provides the user interface through which users interact with the application. The website communicates with a backend via a mostly json API. I'd like to say REST, but let's be real, most of the time it's more like RPC.

A backend in Modern C# with ASP.NET: The application logic is predominantly written in C#, employing services organized using ASP.NET dependency injection. However some logic resides in SQL Views and Stored Procedures. A bad choice? Maybe, but we don't always get to choose.

Database Storage: Data is stored in SQL Server using EntityFramework 7. While EntityFramework simplifies database access, it presents challenges in terms of testing, especially when it comes to mocking.

Application Settings: Any sufficiently complex application probably has a few settings stored in the database. Even a TODO application might have different types of tasks with different workflows defined in the database.

Key Considerations

Testing is not one-size-fits-all; it involves making various decisions and trade-offs based on project requirements and goals. A project may have several test suites with different trade-offs. In this series, we explore different testing styles and goals, considering factors such as:

Speed: It is important, especially in Test-Driven Development (TDD) scenarios, to have tests that run fast, giving feedback quickly. Such tests, must probably be written to focus on individual components, validating their behavior without relying on external dependencies. The trade-off is how far you are willing to go to mock external dependencies. These tests are often called "Unit tests" because they test parts in isolation.
System coverage: Testing parts in isolation while mocking their dependencies only gets you so far. To ensure comprehensive coverage, we delve into integration tests that assess how these components interact when combined. Integration tests provide a more holistic view of the application, examining the integration points where potential issues might arise. True system coverage may require communicating with services outside of the application, such as a real database. The trade-off lie in how far you go to provide outside services equivalent to the production environment, or how far you go to replace them with mocks and/or fakes.
Reliability and Stability: Beyond the functionalities, a robust application must be reliable and stable under various conditions. Load testing, stress testing, and performance testing become crucial. These tests assess how the application behaves under different loads and stress levels, ensuring it can handle real-world usage scenarios without compromising on speed and responsiveness.
Monitoring: No matter how completely we have tested the application logic and reliability, things will get messed up eventually. Monitoring probably ought to be sufficient to debug and fix the problems easily. The trade-offs to be explored include how much detail you want to collect and store.
Maintainability: As the project evolves, tests need to evolve too. Writing maintainable tests involves considering their longevity and ease of modification. Test suites should be adaptable, allowing developers to refactor code confidently without the fear of breaking existing functionalities. Balancing thorough testing with the ability to make changes to the codebase is essential for long-term project health.

In this series, we'll explore these key considerations in depth, offering insights into crafting test suites that strike the right balance between speed, coverage, reliability, and maintainability. By understanding these fundamental principles, you'll be better equipped to make informed decisions tailored to your project's unique requirements.

Conclusion

Testing ASP.NET web applications involves a delicate balance of various testing approaches, each serving a specific purpose. In the articles that follow, we will explore various approaches. Some may be good, some may be crazy. This is exploration, not a thesis. The goal is not to explain the one true way, but to learn.

AutoMapper: converting entities to views at runtime

jpeg729 — Thu, 05 Sep 2019 15:05:53 +0000

I have put off writing this post for quite some time since I didn't have a viable alternative and others have written about the problems they have experienced with AutoMapper. For instance Why I don't use AutoMapper.

Now I do have an alternative, so here goes.

What AutoMapper does

When you use an ORM (object relational mapper) to load data from your database, you often end up loading data into objects (which I will call entities) containing way more data than you actually need at that moment. Automapper lets you transform those objects into smaller data transfer objects (DTOs) more adapted for your need at that moment.

For example, you could have Book and Author classes like this.

public class BookEntity
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string ISBN { get; set; }

    public AuthorEntity Author { get; set; }
}

public class AuthorEntity
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string PreferedGenre { get; set; }

    public List<AuthorEntity> Books { get; set; }
    // I put "List" for ease of understanding, but 
    // EntityFramework 6 actually requires an "ICollection".
}

And you might want to send only the following

public class AuthorWithBooksDto
{
    public string Name { get; set; }
    public List<BookDto> Books { get; set; }
    public int BooksCount { get; set; }

    public class BookDto
    {
        public string Name { get; set; }
    }
}

I put the BookDto class inside the AuthorWithBooksDto in order to avoid reusing it elsewhere in the codebase.

So you define a map using AutoMapper

public class AuthorProfile : Profile
{
    public AuthorProfile()
    {
        CreateMap<AuthorEntity, AuthorWithBooksDto>();
    }
}

And you use it like this...

var authorDto = AutoMapper.Mapper.Map<AuthorWithBooksDto>(authorEntity);

Or even better you can use AutoMapper's queryable extensions to only load the required properties.

var authorDtos = dbContext.Authors.ProjectTo<AuthorWithBooksDto>();

The mapping will be translated into SQL in order to optimise the data transfer.

Upsides

It is super easy to use.
It works nicely with EntityFramework and other ORMs.
It works pretty well.
It is super easy to use (Did I already say that?)

Downsides

If your mappings aren't defined quite right you can get cryptic runtime errors, such as OutOfMemory, or NullReferenceException's that can't tell you exactly what was null.
Since you define the mappings without referring to all the properties that get mapped, your editor cannot tell you exactly which properties are used and where.

Alternatives

AutoMapper does a great job, but it does it at runtime and I think we can do better.

I don't want to have to write all my mappings by hand, but I do want my code editor to be able to tell me exactly where each property is used, and I do want an easy equivalent to AutoMapper's query projection extensions.

This means I need a tool that can generate code for the mappings when I am writing the code. It also has to be able to generate mappings as C# Expressions because that is what EntityFramework uses to generate its SQL queries.

The MappingGenerator extension

If you use Visual Studio 2017+ you can use the MappingGenerator which as its name suggests, generates mappings.

Here is how it works...

Type out the map function's signature

public AuthorWithBooksDto MapFrom(AuthorEntity author)

Press Ctrl+. at the end of the line and choose the proposed code fix

Check the generated code

public AuthorWithBooksDto MapFrom(AuthorEntity author)
{
    return new AuthorWithBooksDto()
    {
        Name = author.Name,
        Books = author.Books.Select(authorBook => new AuthorWithBooksDto.BookDto()
        {
            Name = authorBook.Name
        }).ToList(),
        BooksCount = author.Books.Count
    };
}

Of course, you are going to tell me that isn't an Expression mapping and it can't be used with EntityFramework, and you would be right, but watch this...

Type out the signature, it is a little more complicated, I will grant you that

public Expression<Func<AuthorEntity, AuthorWithBooksDto>> MapAuthorWithBooks =
    entity => new AuthorWithBooksDto { };

Put the text cursor in between the curly braces, press Ctrl+., and choose "Initialize with lambda parameter".

Check the generated code

public Expression<Func<AuthorEntity, AuthorWithBooksDto>> MapAuthorWithBooks =
    entity => new AuthorWithBooksDto
    {
        Name = entity.Name,
        Books = entity.Books.Select(entityBook => new AuthorWithBooksDto.BookDto()
        {
            Name = entityBook.Name
        }).ToList(),
        BooksCount = entity.Books.Count
    };

Test its use

var query = db.Authors.Select(MapAuthorWithBooks);
Console.WriteLine(query.ToString()); // only the required columns are included
var authorsWithBooks = query.ToList();

What do we gain?

Visual Studio no longer tells us that the properties of our entities have zero references.
No more memory overflows

What problems remain?

If a null reference exception happens during the mapping Visual Studio 2017 can't tell you which precise line caused it, so you then have to do things like commenting out most of the mapping until you find the culprit. I imagine nullable reference types will help resolve this problem.
If you want Expression maps and compiled maps you either have to generate code for both, or you have to compile the expression at runtime, in which case you loose the ability to set breakpoints inside the mapping code.
Organising your maps becomes a bigger problem than it was. Adding a static method MapFrom to each Dto class might be a great idea.

Conclusion

AutoMapper is great, and while I can reproduce much of what I can do with AutoMapper using generated mapping code, I am not certain that it is a huge advantage.

The main use case for mappings seems to be generating models to send over the wire, and there are many alternative approaches. gRPC and GraphQL are alternatives that may have their own advantages.

Even if you prefer using AutoMapper, do try out the MappingGenerator extension because it has many useful capabilities.

Using NoSQL as a cache for views

jpeg729 — Tue, 02 Jul 2019 21:24:55 +0000

Last time we spoke about the pros and cons of using EntityFramework to manage our database access. This time we will cover our use of a NoSQL database primarily as a cache. We also use it for fancy full text queries, but we won't cover that in this article.

NoSQL as a cache

In the database we have an Authors table, a Books table, a Publishers table, a Marketers table, a Meetings table, and various other tables containing useful info related to these.

The relationships are vaguely as follows: Each Author has many Books, each Book has a Publisher and a Marketer, (and therefore each Author is linked by extension to several Publishers and Marketers). There are also Meetings of various types which can involve some or all of these actors.

(Disclaimer: these table names are fictitious, however the relationships between them do resemble the sorts of relations that I have to deal with at work.)

Now, we need to be able to display the books in a list with their Titles, Authors, Publishers and various assorted details. We also want the user to be able to specify search terms that could match the book's title, the author's name, the publisher's name, the themes that are found in the book, and so on. Now EntityFramework 6 can do all the fancy joins needed to deliver all of this detail, but the requests are far from optimised, and what's more, we need to deliver all of this information page by page. Besides SQL Server isn't great at full text querying. So we put everything into our NoSQL database and access it from there.

A NoSQL database stores json documents and indexes them for querying. We fill the indices by loading the entities from SQL Server using a bunch of Includes and then we push them into the relevant index in our NoSQL database. The code looks something like this...

var authors = ctx.Authors
    .Include(a => a.Books)
    .Include(a => a.Books.Select(b => b.Publisher))
    .Include(...);

foreach (var batch in authors.Batch(batchsize))
{
    noSqlClient.IndexMany(batch);
}

Naturally, there are other list views that we need to populate. For example, a list of Authors with various accompanying details, and a list of Publishers with different details. Hence we end up with three different indices each containing a subset of the data seen from a different angle.

Bad design

Many of you will tell me that we are doing it wrong, and I will agree with you. It is inefficient and not particularly useful to store entire entities with all their fields, plus their related entities with all their fields when we only need subsets of all that information for our views. Instead we should store view models containing a more limited amount of data sufficient for the views we need to present to the user, plus the fields needed for the various search options. But the app wasn't designed like that and we can't take too much time out from implementing new features, so we change it too quickly.

Difficulties

Obviously, such an architecture comes with a number of drawbacks, for instance...

Keeping the cache up to date
EntityFramework is pretty slow at loading an entity with lots of many-to-many joins

Keeping it up to date

This is a kicker because whenever a publisher's details are modified, for example, we need to update all the authors in the authors' index who have books published by that publisher. Likewise when we update an author's details we need to update his/her document in the authors' index, and the publishers he/she has used in the publishers' index. And so on...

So how do we manage that infallibly and efficiently?

Well, we manually transformed the list of Includes into a set of recipes for detecting which indexed entities would be affected by an update to any child entity. Then we added some custom code that would automatically run each time we call ctx.SaveChanges(). This custom code uses the recipes to detect which documents of each index need updating, then loads the root entities from our NoSQL database, loads the child entities from the database with any necessary sub-Includes, and patches the root entities and stores the result back into our NoSQL database. This somewhat more efficient than loading the root entities with their Includes and re-indexing the whole lot.

EntityFramework join optimisation

We noticed recently that when loading the authors in order to fill the authors' index, EF would pause for nearly a full minute before it started transferring any data. We tested the query itself and it wasn't anywhere near that expensive.

EntityFramework.Plus provides an .IncludeOptimized extension method that is faster than EntityFramework's .Include method. But with two drawbacks. It doesn't support many-to-many joins, and it doesn't support .AsNoTracking(). Now obviously, if we are loading entities solely in order to load them into our NoSQL database, we don't need EntityFramework to track the changes to those entities, so we should be able to optimise a little by asking EF not to track changes.

We ended up optimising this by loading the Authors with AsNoTracking, then loading the Books in a separate query also with AsNoTracking and manually attaching each book to the right author. The total time went down from 1 minute 45 seconds, to around 25 seconds. Running the queries in parallel allowed us to nearly halve that again.

Loading an Author from SQL Server using this method takes around 30-40ms, whereas loading the same Author with all the related entities from our NoSQL database takes only ~1ms.

Code maintenance

Unfortunately, instead of a single list of Includes we now have some other bits of code to maintain as well.

The recipes for keeping the indices up-to-date could be fairly easily generated from the list of Includes using reflection, but we haven't taken the time to do it yet.

The code for the schema generation is fully automatic and needs no maintenance. It just needs an up-to-date list of Includes and does its magic automatically. Personally, I am very happy about this because the code that does this is a pretty ugly mess of reflection and Expression tree building.

The code for optimised loading needs adjusting manually each time. In theory this code could also be generated automatically at runtime, but this would be pretty hard to do. The tricky thing is figuring out which navigation properties to use to attach child entities to, though I suspect we could extract those details from EF 6 if we really tried, (or if we read parts of the source code for EntityFramework.Plus).

Where to go from here

Storing view models instead of full entities may represent a decent efficiency gain, but the speed-up could turn out to be negligible. Currently, the cache updates are managed by recipes that could be automatically generated and it is hard to see how we could achieve something similar if we used view models instead. Automapper's ProjectTo might be able to produce an Expression tree that we could usefully parse and convert into recipes for detecting the required updates.

I have been able to use a list of Includes to generate the SQL query necessary to make SQL Server dish up a json document containing an entity and its related entities, and I am confident that the resulting query could be used to create a computed column, and that the resulting column could be indexed in order to force SQL Server to keep the json document up to date. That would solve our slow loading problems and our cache update difficulties in exchange for slower SQL updates, and we would still need our NoSql database for smarter text queries.

That said, we might decide that the web app must be usable offline, in which case we would keep enough data cached in the browser to allow us to run text search queries via javascript. This could eliminate the need for our NoSQL database.

Conclusion

We have faced some serious difficulties in our use of a NoSQL database, but I am confident that we have overcome the worst of these. There are many ways in which we could improve this architecture and I can't wait to see what we will be able to achieve.

Imagining a better EntityFramework

jpeg729 — Sun, 23 Jun 2019 21:10:28 +0000

There is a lot to like in EntityFramework... and some less desirable parts.

The good

Automatic translation of C# Linq queries to SQL for efficient querying

For example, the following asks the database to filter the books rather than loading them all and discarding the books by other authors.

var books = ctx.Books
    .Where(b => b.Author == "John Smith").ToList();

Using anonymous objects to select only the data you need

For example, the following only fetches the Authors.Name and Books.Title columns.

var authorNamesAndBookTitles = ctx.Authors
    .Select(a => new 
    { 
        Name = a.Name, 
        Books = a.Books.Select(b => b.Title) 
    });

Using Automapper's ProjectTo to load only the data that you want

For example, if AuthorDto contains only a subset of the properties of Author, the following will only fetch the required columns.

Mapper.CreateMap<Author, AuthorDto>();

var authorsAndBooksDtos = db.Employees
    .ProjectTo<AuthorDto>().ToList();

Explicit joins for (mostly efficient) loading of related data

This will load all the authors along with the books each one has written.

var authorsWithBooks = ctx.Authors
    .Include(a => a.Books).ToList();

Automatic change tracking

Just load some data, modify it, and then call SaveChanges() and all the changes get saved.

var authorWithBooks = ctx.Authors
    .Include(a => a.Books)
    .Where(b => b.Id == authorId).First();

authorWithBooks.Name = "new name";
authorWithBooks.Add(new Book { Title = "book title" });

ctx.SaveChanges();

Automated generation of code-first migrations

Just change your entity classes, run Add-Migration NameOfMigration in the console, and a new migration class gets generated.

The not so good

You can't mix returning anonymous objects and entity types

For example, the following won't work.

var authorNamesAndBooks = ctx.Authors
    .Select(a => new 
    { 
        Name = a.Name, 
        Books = a.Books
    });

Change tracking

Coding a feature usually involves loading some data, verifying the state of the data, modifying the data, and maybe sending an email or generating a document. Change tracking makes this pretty easy.

But if the verification part is done by a function written by a less experienced developer, you just have to hope that it doesn't modify the data. For example, the following is valid code...

if (author.IsActive = true) { ... }

but it mistakenly assigns true to author.IsActive, and this change will be persisted.

Explicit joins are inefficient when loading data from many related tables

Unfortunately, when you include data from many related tables the query that is generated is not particularly efficient. Loading the related entities separately can often be quicker.

EntityFramework.Plus provides IncludeOptimized to help with this scenario, but doesn't work with many-to-many relationships.

Related entities can be included unexpectedly even with AsNoTracking()

For example, this loads an author with his books and nothing else right?

var authorAndBooks = ctx.Authors
    .Where(a => a.Name == "John Smith")
    .Include(a => a.Books).ToList();

So why is authorAndBooks.First().Author not null?

My guess is that as EntityFramework had loaded the author into memory, it realised it could set the Author property of each book correctly from the data in cache.

This could be problematic when you want to send a minimal set of data over the wire.

Migrations

EntityFramework's Add-Migration command compares the current state of the database, the snapshot of the database shape stored in the most recent migration, and the shape of your entity classes.

Hence, if you add migrations to two independent branches and then merge the result EntityFramework assumes that the least recent migration hasn't been generated nor applied. The fix is easy but tedious, you have to generate a new migration using the -IgnoreChanges option in order to tell it that the current database state is good.

Saving untracked entities is fraught with danger

For example, the following code duplicates the user.

var untrackedUser = ctx.Users.First(u => u.Id == userId).AsNoTracking();
var book = new Book 
{ 
    Title = "new book title",
    Author = untrackedUser,
};

ctx.Books.Add(book);
ctx.SaveChanges();

Untracked entities can come from many sources, from data sent from a client app, from a NoSQL cache, from a query with AsNoTracking, etc.

Might there be a better way...?

Here are a few ideas?

Migrations

An upgrade to EntityFramework Core would solve the problem, but would exchange it for another. Namely, many-to-many joins are not supported. In EntityFramework 6 you simply need ICollection properties in both classes, for example...

class User 
{
    public string Name { get; set; }
    public ICollection<OnlineCourse> OnlineCourses { get; set; }
}

class OnlineCourse
{
    public string Title { get; set; }
    public ICollection<User> Users { get; set; }
}

whereas in EntityFramework Core you need to add an Enrolment entity in between them, and link Users to their Enrolments rather than directly to their OnlineCourses.

class Enrolment
{
    public User User { get; set; }
    public OnlineCourse OnlineCourse { get; set; }
}

This might not be such a bad thing as it makes things more explicit. On the other hand, merging migrations is an infrequent hassle and definitely not a showstopper for us.

Imagining a new API for writing data to the database

EntityFramework.Plus provides a bulk update API that allows you to modify properties of a an entity without first loading the entities. Here is one of their examples...

// UPDATE all users inactive for 2 years
var date = DateTime.Now.AddYears(-2);
ctx.Users.Where(x => x.LastLoginDate < date)
         .Update(x => new User() { IsSoftDeleted = 1 });

However this API does not support linked entities.

Could we create a similar API that did support linked entities? Here are a few use cases that I would like it to support...

Setting a singly linked property without modifying other properties of the linked entity
Setting a singly linked property and simultaneously modifying other properties of the linked entity
Creating a new entity and adding it to a list of linked entities on another entity
Adding an existing entity to a list of linked entities on another entity, with or without modifying some of its properties.
Removing an item from a list of linked entities without necessarily deleting the linked item

Maybe a call to our imaginary ExplicitUpdate method could return a list of modified properties with their old and new values...

More details to follow...

What about other ORM's?

Dapper is a well known alternative to EntityFramework with a reputation for being fast. But it is only a micro-orm which means that you don't get migrations and you have to write most of your SQL queries by hand. Now I know that I can write SQL queries that are less efficient than those that EntityFramework writes, and I am sure that I would spend weeks rewriting our queries if we decided to move to Dapper.

The thing micro-orm's don't give you is easy migrations. So we would need to find another system for migrations and use T4 to regenerate our entity classes every time.

Micro-ORM's such as Dapper, PetaPoco, linq2db, and many others seem like decent projects, but I can't see us porting our big existing app to any of them in a hurry.

Insight.Database seems to be a slightly more interesting alternative.

Yet another option would be to hide the database access code in an F# project and use one of their SQL Server type providers. Instead of generating model classes using T4, the compiler connects to the database and generates the required classes on the fly. We could still use EntityFramework for legacy code and for migrations, and new code could use a new data access method with very little overhead.

But still, our best bet seems to be to put up with the migrations issue and to add a new API like bulk update on top of EntityFramework.

Conclusion

Immutable data and/or an explicit write API seems to be a sensible way forward for more reliable and testable software.

The quest for the perfect software architecture

jpeg729 — Tue, 18 Jun 2019 20:58:13 +0000

In this series I shall dive into topics such as ORM's, automatic data object mapping, dependency injection and other staples of modern software development. I shall examine the pros and cons of each, and consider any alternative approaches that I have been able to find.

Who am I ?

I have been working as the lead developer on a medium sized architecture for several months now. Some parts are hard to follow spaghetti code, other parts are much clearer. I worked with the previous project lead to develop a new architecture that was supposed to give us structure and help us develop faster and with fewer bugs, and yet we find it cumbersome and not entirely bug free. We suspect that it may be starting to slow us down.

Maybe I am deluded, maybe I am an incorrigible dreamer, but I can't help wondering whether there isn't a better way...

The current architecture

We store our data in SQL Server. The data structure is defined in C# classes that EntityFramework uses to generate the database schema and migrations.

For faster loading and more advanced querying we store composite views of this data in a NoSQL database. Basically we use it as a glorified cache, and we have trouble keeping it up-to-date.

The cache updates and a small number of business rules are run via code that intercepts each write operation in EntityFramework.

We use HangFire to queue and run jobs that must run in the background. HangFire gives us a nice interface and automatic retries for free.

The code vaguely follows a layered architecture, but the passage of father time and several interns hasn't done it any favours.

Currently the app runs on a single server, serving a small number of users, but many apps do not have this luxury. This begs the question: What might we need to change in order to run at scale from the cloud?

In this series

This is a provisional roadmap and may change.

SQL ORM's and in particular the one we use: EntityFramework.
- Querying and reading data
- The poor performance of reading data from linked tables
- Change tracking and why it could be bad
- Could there be a better way?
- Pros and cons: the bits I like and those I would rather avoid.
NoSQL database
- Use as a cache and the difficulty of keeping it up to date
- NoSQL vs SQL: could we have both in one storage provider?
AutoMapper
- What it can do
- Why is that bad?
- Runtime mappings vs automated code generation
Dependency injection
- How we use it
- Why we use it and what we might really need it for
- Double dependency trees
- Alternative approaches
Ideas from the world of functional programming, part 1
- Immutability
- How to combine immutability and EntityFramework
- How to combine immutability and AutoMapper or its alternatives
Ideas from the world of functional programming, part 2
- Fun with .Select, .SelectMany, Linq and the query syntax
- What should we inject and where?
Reacting to changes: events, actors and stuff
- The need to react to certain types of changes
- How we manage it
- Could we use Microsoft Orleans, Akka, or something else instead?
What if we had to run at scale in the cloud?
- What might we have to do differently?
- What might we prefer to do differently?
Tying it all together
- My favourite ingredients
- A recipe for combining them
(some time later) How it all turned out
- The bits we liked and the bits we didn't like
- How we would do it if we started afresh.