Когда можно стирать абстракцию между данными и логикой? - PullRequest
2 голосов
/ 06 октября 2011

Я имею в виду обращение к конкретным строкам базы данных по их идентификатору, из кода или указание имени класса в базе данных.Пример:

У вас есть таблица базы данных с именем SocialNetwork.Это таблица поиска.Приложение не пишет и не удаляет его.Это главным образом для целостности базы данных;скажем, весь шебанг выглядит так:

SocialNetwork table:

Id | Description
-----------------------------
1  | Facebook
2  | Twitter

SocialNetworkUserName table:

Id | SocialNetworkId | Name
---------------------------------------------------
1  | 2               | @seanssean
2  | 1               | SeanM

В вашем коде есть какая-то особая логика, которую необходимо выполнить для пользователей Facebook.Обычно я создаю в коде перечисление или некоторые константы класса, чтобы легко ссылаться на него, например:

if (socailNetwork.Id == SocialNetwork.FACEBOOK ) // SocialNetwork.FACEBOOK = 1
  // special facebook-specific functionality here

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

Другой вариант, который я могу придумать, - это указать имя класса или делегата в базе данных, но это даже хуже IMO, потому что теперь вы не только нарушили разделение между данными и логикой, но выВы привязали себя к одному языку сейчас.

Я много шума из ничего?

Ответы [ 2 ]

1 голос
/ 06 октября 2011

Я не вижу проблемы.

В какой-то момент ваш код должен что-то делать. Facebook - это настоящая социальная сеть с собственным API, и вы хотите, чтобы она делала в своем коде специфичные для Facebook вещи. Если ваши задачи не являются тривиальными, поместить все специфичные для Facebook вещи в базу данных будет означать головную боль в вашем коде. (Что эквивалентно «Нравится» в Twitter, например?)

Если запись Facebook отсутствует в вашей базе данных, код для Facebook не будет выполнен. Вы можете сделать это много.

1 голос
/ 06 октября 2011

Да, но с оговоркой, что «это зависит». Это вряд ли изменится, но.

Хранение имени класса или делегата, вероятно, плохо, но хранение токена, используемого классом или делегатом factory , не так, потому что оно не зависит от языка - но вы всегда будете иметь проблема необходимости поддерживать соединение где-то . Если у вас нет таблицы специфических для языка вещей, привязанной к этому столу, в этот момент, я полагаю, вас застрелят.

Вместо постоянного сравнения в основном коде, IMO, такая ситуация хороша для фабрики и т. Д. шаблон, поиск по перечислению и т. д. для реализации поиска / поведения класса, специфичного для сети. Основной код не должен заботиться о том, как он реализован, что он делает прямо сейчас - , что часть является подлинной проблемой.

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

...