From Naked Objects to Naked Functions

Functional programming (FP) is, today, roughly where object-oriented programming (OOP) was in the late 1990s. Pure FP languages are gaining popularity, and mainstream languages increasingly support FP idioms. There are some application domains where FP has already become the dominant paradigm – scientific computing, big data, some fin-tech – but there are also substantial application domains where FP has made little impact, one such being transactional enterprise applications built on relational databases. Granted, this is no longer considered to be the ‘hot’ end of systems development, but it still accounts for a huge proportion of commercial programming. Developers working on such systems today might use functional idioms where they can, but it is rare to see one built using FP as the core design ethic.

This situation might be attributed to traditional conservatism in that sector, but I believe there is a bigger issue, which derives from the central conundrum of FP, elegantly articulated by Simon Peyton Jones (lead on the Glasgow Haskell Compiler):

Investigating a Memory Leak in Entity Framework Core

Don't let memory leaks become floods

The terms "memory leak" and ".NET application" are not used together very often. However, we recently had a spate of out of memory exceptions in one of our .NET Core web applications. The issue turned out to be caused by a change in behavior in Entity Framework Core, and whilst the eventual solution was incredibly simple, the journey to get there was both challenging and interesting.

The system itself is hosted in Azure and is comprised of an Angular SPA front-end and a .NET Core API on the back-end, using Entity Framework Core to talk to an Azure SQL Database. As a software consultancy specializing in .NET development, we've written many similar applications before.

How to Configure Entity Framework Caching

Distributed Caching With Entity Framework

The Entity Framework is a set of technologies in ADO.NET that support the development of data-oriented software applications. With the Entity Framework, developers can work at a higher level of abstraction when they deal with data and can create and maintain data-oriented applications with less code than in traditional applications.

NCache introduces the caching provider, which acts between Entity Framework and the Data source. The major reason behind the EF Caching provider is to reduce database trips (which slow down application performance) and serve the query result from the cache. The provider acts in between the ADO.NET entity framework and the original data source. Therefore, the caching provider can be plugged without changing/compiling the current code.

Using Junction or Associative Tables in Entity Framework Core

When I first encountered Entity Framework (EF), I always gravitated towards a database-first option. Back when Entity Framework appeared, there wasn't a code-first option.

My thinking towards this approach was your database holds the data. If your database wasn't designed properly from the start, and you generate your entities based on the database design, your code (entities) may suffer.