Question

I’m really thinking that in the years ahead, I will be creating internal apps in both Rails and .Net Entity Framework that will need to work nicely again the same SQL Server or MySql database tables.

At this point I’m pretty much greenfield in the table designs, so I can name my columns anything I want to. I’ve studied Rails and .Net EF enough to understand how their conventions work for the table and fieldnames.

Unfortunately, there are some conflicts between the two conventions, and it seems that whatever choice I make will lead to abandoning the conventions of one or the other, and I will have to manually enter more information in my classes or associations to tell each framework how to work with the tables.

For instance, .Net EF seems to show a best practice of fields with no underscores in the field names, whereas Rails expects underscores for certain field names.

Example:

CustomerId (EF) vs. customer_id (Rails) [Foreign key fields]

Then there is the issue of the special Rails fields “created_at” and “updated_at”… Well, my preference will be to NOT use underscores in ANY of my field names, but yet if I do that, Rails will not (I’m assuming), make use of the fields if they are named “CreatedAt” and “UpdatedAt”.

Any thoughts or advice here?

Answer 1

The EF doesn’t really care about your field names.

FxCop/Code Analysis will care about property names, but property names don’t have to be the same as field names.

So:

1. Let Rails have its magic names.
2. Create an EF model.
3. Go to the entity, select the created_at property, and change its Name to CreatedAt in the designer.

Now your C# class has a “standard” casing but Rails gets the DB column name it wants.