Хорошие имена полей, которые подходят для Rails и приложений .Net - PullRequest
1 голос
/ 09 сентября 2010

Я действительно думаю, что в ближайшие годы я буду создавать внутренние приложения как в Rails, так и в .Net Entity Framework, которые снова должны будут хорошо работать с теми же таблицами базы данных SQL Server или MySql.

На данный момент я в значительной степени ориентируюсь в дизайне таблиц, поэтому я могу называть свои столбцы как угодно.Я достаточно изучил Rails и .Net EF, чтобы понять, как их соглашения работают с именами таблиц и полей.

К сожалению, между этими двумя соглашениями есть некоторые противоречия, и кажется, что любой выбор, который я сделаю, приведет котказ от соглашений того или другого, и мне придется вручную вводить больше информации в мои классы или ассоциации, чтобы рассказать каждой платформе, как работать с таблицами.

Например, .Net EF, кажется, показываетЛучшая практика для полей без подчеркивания в именах полей, тогда как Rails ожидает подчеркивания для определенных имен полей.

Пример:

CustomerId (EF) против customer_id (Rails) [Поля внешнего ключа]

Затем возникает проблема со специальными полями Rails "create_at" и "updated_at" ... Что ж, я предпочитаю НЕ использовать подчеркивания в ЛЮБОМ из моих имен полей, но все же, если я это сделаю,Rails не будет (я предполагаю) использовать поля, если они названы «CreatedAt» и «UpdAt».

Любые мысли или советы здесь?

1 Ответ

2 голосов
/ 09 сентября 2010

EF на самом деле не заботится об именах ваших полей.

FxCop / Code Analysis будет заботиться об именах свойств, но имена свойств не обязательно должны совпадать с именами полей.

Итак:

  1. Пусть у Rails есть свои магические имена.
  2. Создайте модель EF.
  3. Перейдите к сущности, выберите created_at и измените его Name на CreatedAt в конструкторе.

Теперь ваш класс C # имеет "стандартный" корпус, но Rails получает желаемое имя столбца БД.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...