Month: October 2015

Entity Framework Pitfalls: DbConfiguration Classes Are Automatically Loaded

Entity Framework, since version 6, allows us to specify certain aspects of its configuration by code through a DbConfiguration-derived class. This configuration can be specified in one of three ways:

However, if there is a DbConfiguration-derived class in the same assembly as your DbContext, it will be automatically set as the configuration class, provided that:

  • It is public;
  • It is non-abstract;
  • It has a public parameterless constructor.

So, a DbConfiguration in the same assembly as the DbContext is automatically loaded. If there is more than one, the DbContext constructor will throw an exception.

Java Flaws

One thing I didn’t talk about in my Java vs C# series (by the way, more to come soon) was some things that I think Java got wrong.

One of these things has to do with serialization. Java offers the Serializable interface, which is analogous to the [Serializable] attribute in the .NET world: both state that a class can be safely serialized (whatever that means). Then, Java has the transient keyword, used for marking a field as non-serializable! See my point? One – the interface – is an API, the other is a built-in language construct! .NET is more coherent, in that it has a [NonSerialized] attribute for this purpose.

Another one is method overriding. In Java, all methods are virtual by default, unless marked as final. Then, there is an annotation, @Override, that is now mandatory (since the introduction of annotations in Java) in overridden methods. Again, mixing APIs with language constructs.

The last one I want to talk about is default and static methods in interfaces. For those who don’t know, this means the possibility to define methods with their implementation in interfaces, something that should make all OOP lovers roll their eyes! I guess this was Java’s response to extension methods in .NET, but, again, it is something that I think .NET got right.