Clean event handler invocation with C# 6

Jon Skeet's coding blog

The problem

Invoking event handlers in C# has always been a bit of a pain, because an event with no subscribers is usually represented as a null reference. This leads to code like this:

It’s important to use the handler local variable, as if instead you access the field twice, it’s possible that the last subscriber will unsubscribe between the check and the invocation:

Now this can be simplified slightly using an extension method:

Then in each event, you can write a single line:

However, this means having a different extension method for each delegate type. It’s not too bad if you’re using EventHandler but it’s still not ideal.

C# 6 to the rescue!

The null-conditional operator (?.) in C# 6 isn’t just for properties. It can also be used for method calls. The compiler does the right thing (evaluating the expression only once) so you can do…

View original post 407 more words

Dependency Injection and highly coupled objects

Coding Journeyman

power-plugI consider that Dependency Injection (DI) is a very helpful pattern, I love to use it in order to reduce the coupling in my code and it helps me when writing unit tests. But sometimes the code depends on objects that are difficult or impossible to mock.

The HttpContext class of the ASP .NET MVC framework is one example of this kind of object.

I created the following Controller and View as examples:

publicclass IndexController : Controller
{[HttpGet]public ActionResult Index(){string[] languages = HttpContext.Request.UserLanguages;return View(model:languages);}}
@model string[]
@{
    Layout = null;
}
 
<!--DOCTYPE html>
 
<html><head><metaname="viewport"content="width=device-width"/><title>Index</title></head><body>

View original post 759 more words

Custom Naming Convention

The CodeFluent Entities Blog

Since CodeFluent Entities infers a meta-model from your model, before any producer is called to generate a single line of code, a full representation of your application is in-memory. Thanks to this inference step and the resulting meta-model, developers can apply application wide changes.

One of the possible application wide changes is to change the way all database objects are named through a naming convention. By default a set of naming conventions are provided by CodeFluent Entities:

  • FormatNamingConvention
  • LowerCaseNamingConvention
  • UpperCaseNamingConvention
  • DecamelizeNamingConvention
  • DecamelizeLowerCaseNamingConvention
  • DecamelizeUpperCaseNamingConvention

And you can also implement your own naming convention to fit your needs as we’ll see in this post.

Create the custom Naming Convention

The naming convention is a class so we create a class library project and add references to

  • CodeFluent.Runtime.dll
  • CodeFluent.Model.dll
  • CodeFluent.Model.Common.dll

Those DLL are located in the installation folder of CodeFluent Entities.

Create a class that implements IProjectNamingConvention or inherits from an existing…

View original post 63 more words

A Use for Partial Classes/Structs

The keyword partial has been with us for a while now. Until recently I couldn’t find a use for partial classes/structs unless some of the code is auto generated and you want to make sure you don’t interfere with auto generated code. That is until recently I have been asked to create a struct representing a local date – a data that is not affected by time-zones and lacks a time component,

To make it as close as a native CLR type I had to implement a bunch of interfaces, ISerializable, IEquitable<T>, IXmlSerializable. In addition it had to implement some explicit and implicit convertions, !=, ==, >=, <=, > and < operators. Soon, what seemed like a simple struct grew into couple of thousands lines of code,

There is nothing preventing you from putting all the code into one big file, however I think I found a more elegant solution – use the partial keyword and split one large LocalDate by either the interface being implemented or things it’s implementing. So I ended up with:

  • LocalDate.ISerializable.cs
  • LocalDate.IEquitable.cs
  • LocalDate.Operations.cs
  • LocalData.Conversions.cs

I have also used one of the Visual Studio plugins to nest all of those files under a single LocalData.cs.

So far I couldn’t come back with a single draw back of such approach. Please let me know if there are any!

Unity Interception Extension

DarioSantarelli.Blog(this);

Starting from Enterprise Library 5.0, Unity supports interception mechanisms which captures the call to an object at invocation time and provides the full implementation of the object through lightweight code generation (ILEmit). It’s something very similar to the aspect-oriented programming (AOP) approach.

However, Unity is NOT an AOP framework implementation for the following reasons:

  • It uses interception to enable only preprocessing behaviors and post-processing behaviors.
  • It does not insert code into methods, although it can create derived classes containing policy pipelines.
  • It does not provide interception for class constructors.

Instance Interception VS Type Interception

With instance interception, when the application resolves the object through the container,

  1. The Unity interception container obtains a new or an existing instance of the object and creates a proxy.
  2. Then it creates the handler pipeline and connects it to the target object before returning a reference to the proxy.
  3. The client then calls methods…

View original post 980 more words

Design Patterns – Command and Strategy

These two patterns are quite often mixed up, since they both perform an action when invoked.

However there are quite substantial difference:
1) Command should only be used as a trigger for a more complex action and should have no computational logic.
2) Strategy in the meantime encapsulates logical operations.

In simple terms command should have as little logic as possible, whereas strategy might encapsulate some complex calculations. It is also possible that a command triggers a strategy to be executed.

An example from WPF would be a particular control bound to an instance of ICommand which in turn could run a particular strategy.

Design Pattern – Abstract Factory

Abstract Factories are used to provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Consider an example where we need to create a service for sending data. The data could be sent using various means: by calling a web service, WCF service or by using plain sockets.

To avoid tight coupling the object that sends the data should not be aware of how the data is sent. That’s where abstract factory comes into play. Assuming that all senders implement a  common interface, all the code has to do is call the method that accepts data in whichever format. The benefit of that approach is that we can later easily substitute the protocol for sending data without making any changes to the object that sends data.

In addition, the abstract factory allows the creation of multiple instances of the class responsible for sending data. This is a very useful property when we use dependency injection. The abstract factory can be injected through the constructor and the object responsible for sending data is free to create as many instances of the service as it requires.

That pattern not only solves the coupling problem and separation of concerns, but also allows for better unit testing, since the abstract factory can be very easily mocked.

Design Pattern – Adapter

The purpose of the adapter pattern is actually quite simple. It converts one interface to another one, thus making it possible for classes to work together where the interfaces are different.

Real World Example

Because it’s such a common pattern I had to think for a while before coming up with an example.

Say, our application has to export some data in various formats – excel, pdf etc. It would be quite likely that third party libraries for each of the formats have different interfaces. We could of course write a switch statement, but the better solution would be to wrap each of the third party libraries into a class that implements a common interface. Then all we have to do is resolve the wrapper based on the format. Since the wrapper would implement a common interface the task of exporting data become relatively simple

Breaking the CLR Type Safety

Programming fun

As you might have already heard .Net is type safe. Specifically talking CLR provides type safety at runtime, some .Net languages (example: C#) work with CLR to provide type safety at compile time.

So what does the term type safe mean?

Let’s find what Wikipedia says:

In computer science, type safety is the extent to which a programming language discourages or prevents type errors. A type error is erroneous or undesirable program behavior caused by a discrepancy between differing data types for the program’s constants, variables, and methods (functions), e.g., treating an integer (int) as a floating-point number (float). Blah blah blah..

Ok, Now we know that type safety has something to do with preventing the programmer from accessing the type as other than what it is.

Well, C# and CLR are pretty good in this, they work together to push you into the Pit…

View original post 379 more words

Blog at WordPress.com.

Up ↑