multiple assembly "conventions" (EF vs AO)

[adamfoneil]

Developers have conflicting and strongly held beliefs about C#-to-SQL conventions -- for example what the [Key] and [ForeignKey] attributes represent exactly, and so on. Not to mention special attributes like my own [References] attribute in AO.Models. In ModelSync, the [Key] attribute is handled in a very specific way, resolving to one of several key configurations (primary, unique constraint, identity). Some devs want Guid keys, for example, some want int or long or string. Some devs want implicitly pluralized table names. (I don't.) The point is, it's very difficult to get agreement on universal database conventions.

The goal for this issue is to create an IAssemblySource that works with assemblies intended for Entity Framework EFModelBuilder

This will sit alongside the AOModelBuilder.

The EF version should accomplish much the same thing as the AO version, but should not reference AO.Models.

[adamfoneil]

@desirablecoder this is a bit different from what we talked about earlier, but this is really where I was trying to get to. After some thought, I don't like my idea of an abstract DbConventions class. There's already an interface that will work here IAssemblySource. There's no need to make a new abstract class IMO.