IResult – A Robust Option Type for C#

Jeremy Madden. CodeProject. 2017-06-09.
The features introduced in C# 7.0 make it just a little easier to introduce some functional-programming style patterns into enterprise C# code. One of the features that had me particularly excited was pattern matching, particularly in switch blocks.
IResult utilizes some of these new features to emulate an the Option type from F#, including helper functions like Bind, Map and Fold.

[IResult – A Robust Option Type for C#]

Top .NET Software Errors: 50 Common Mistakes and How to Fix Them

Angela Stringfellow. Stackify. 2017-06-13
Developing in .NET provides several powerful benefits, including less overall code, improved security, ease of updates/changes, and language independence.
That said, the system isn’t without errors and problems. From common exceptions to coding mistakes to incorrect assumptions, most of these issues come down to programmer error.
The list below shares the 50 top .NET software errors from around the web. It includes exceptions, broken data bindings, memory leaks, LINQ issues, mistyping errors, and dozens more. We also look at ways to fix each one.
When you’re ready to start coding, download our free guide to .NET Profilers for some insider knowledge and everything you need to know about code profiling for .NET. And while you’re at it, be sure to check out Prefix, our own lightweight profiler for .NET and Java developers. (And, if you’re thinking about .NET Core, read our opinion on why it’s the next big thing here.)

[Top .NET Software Errors: 50 Common Mistakes and How to Fix Them]

The .NET Language Strategy

Mads Torgersen. .Net Blog. 2017-02-01.
I am constantly aware of the enormous impact our language investments have on so many people’s daily lives. Our languages are a huge strength of the .NET platform, and a primary factor in people choosing to bet on it – and stay on it.
I’ve been here on the .NET languages team at Microsoft for more than a decade, and I’ve always seen us have developers’ interests first and foremost in our minds as we moved the languages forward. The open source revolution (of not just the .NET languages but the whole .NET stack) has improved the conversation dramatically, and – I think – helped us to make better choices. However, we haven’t always been good at sharing how we make those decisions: Our language strategy; the framework for how we think about each of our .NET languages and chart their evolution.
This post is meant to provide that additional context for the principles we use to make decisions for each language. You should consider it as guidance, not as a roadmap.

[The .NET Language Strategy]

ASP.NET MVC Shopping Cart with C#, EF, SQL Server-Part1

Web Development Tutorial. 2016-11-21.
In this ASP.NET MVC Tutorial Series, we will follow a step by step approach to develop an Online Shopping Cart using ASP.NET MVC, C#, Entity Framework and SQL Server with database first approach. After reading this Web Development Tutorial, user must be able to understand that how to build an ASP.NET MVC Shopping Cart using above mentioned technologies very easily? The article explains the necessary details, screenshots of each step and finally the source code at the end of the series.
[ASP.NET MVC Shopping Cart with C#, EF, SQL Server-Part1]

Advanced Use Cases for the Repository Pattern in .NET

Jonathan Allen. InfoQueue. 2016-10-25.
In our previous article, Implementation Strategies for the Repository Pattern with Entity Framework, Dapper, and Chain, we looked at the basic patterns needed to implement a repository. In many cases these patterns were such a thin layer around the underlying data access technology they were essentially unnecessary. However, once you have a repository in place, many new opportunities become available.
When designing a repository, you should be thinking in terms of “what must happen”. For example, let us say you have a rule that whenever a record is updated, its “LastModifiedBy” column must be set to the current user. Rather than trying to remember to update the LastModifiedBy in application code before every save, you can bake that functionality right into the repository.
By treating your data access layer as a standalone library that manages all of the “must happen” details, you can dramatically reduce implementation errors. At the same time, you can simplify the code that is built on top of the repository, as it no longer needs to be concerned about bookkeeping tasks.
Note: where appropriate, this article will include code samples for Entity Framework, Dapper, and/or Tortuga Chain. However, you will find most repository features can be implemented in an ORM-agnostic fashion.
[Advanced Use Cases for the Repository Pattern in .NET]

Implementation Strategies for the Repository Pattern with Entity Framework, Dapper, and Chain

Jonathan Allen. InfoQueue. 2016-10-14.

In modern enterprise development it is common to use a multi-layered approach to building one’s data access layer (DAL). When using C#, the lowest layer of the DAL is almost always ADO.NET. However, that can be a clumsy library at times so it is common to layer upon it an ORM. Then to enable mocking and hide the ORM’s details, the whole DAL is wrapped inside a repository.
In this series we’ll be looking at techniques for building a repository using three different styles of ORM:
•Entity Framework: A tradition “full feature” or “OOP” style ORM
•Dapper: A lightweight micro-ORM that focuses primarily on result set mapping.
•Tortuga Chain: A fluent ORM based on functional programming concepts.
This article will focus on the basic functionality that one would find in a typical repository. In part two, we’ll look at advanced techniques that one would implement on a case by case basis.
[Implementation Strategies for the Repository Pattern with Entity Framework, Dapper, and Chain]