Разработка методов, связанных с базой данных, которые лучше возвращать: верно / неверно или затронуты строки?

У меня есть несколько методов, которые выполняют изменение данных в базе данных (вставка, обновление и удаление). ORM Я использую возврат строки , затронутые Int значение для этих типов методы. Что я должен вернуть для «моего метода», чтобы указать состояние успеха / неудачи операции?

Рассмотрим код, который возвращает int:

A.1

public int myLowerLevelMethod(int id) {
    ...
    int affectedRows = myOrm.deleteById(id)
    ...

    return affectedRows;
}

Тогда использование:

А.2

public void myOtherMethod() {
    ...
    int affectedRows = myLowerLevelMethod(id)

    if(affectedRows > 0) {
        // Success
    } else {
        // Fail
    }
}

Сравните с использованием логического:

B.1

public boolean myLowerLevelMethod(int id) {
    ...
    int affectedRows = myOrm.deleteById(id)
    ...

    return affectedRows > 0;
}

Тогда использование:

БИ 2

public void myOtherMethod() {
    ...
    boolean isSuccess = myLowerLevelMethod(id)

    if(isSuccess) {
        // Success
    } else {
        // Fail
    }
}

Какой из них (A или B) лучше? Или плюсы / минусы каждого?

Другой вариант - вернуть объект результата вместо базовых типов. Например:

OperationResult deleteResult = myOrm.deleteById(id);

if (deleteResult.isSuccess()) {
    // ....
}

При этом, если по какой-то причине вам нужно вернуть количество затронутых строк, вы просто можете добавить метод в OperationResult:

if (deleteResult.isSuccess()) {
    System.out.println("rows deleted: " + deleteResult.rowsAffected() );
}

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

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

Ни один программист не будет винить вас, потому что он / она должен написать это, чтобы проверить, не получили ли они какие-либо изменения во время операции:

if(affectedRows > 0) {
    // success
} else {
    // fail
}

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

Кстати: если под «отказом» вы подразумеваете синтаксическую ошибку запроса (в этом случае число затронутых строк, очевидно, равно 0), то выбрасывание исключения будет более уместным.

Я бы не рекомендовал ни одного из них. Вместо этого ничего не возвращайте (void) в случае успеха и генерируйте исключение при ошибке.

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

Вопрос в том, как указать успех / ошибку. В этом случае достаточно сообщить о неудаче, выдав исключение и ничего не возвращая при успехе. Почему я должен предоставлять больше, чем нужно пользователю?

Могут произойти сбои / исключительные ситуации, и тогда вам придется иметь дело с ними. Используете ли вы try / catch для этого или проверяете коды возврата, это вопрос стиля / личных предпочтений. Идеи try / catch заключаются в следующем: отделить нормальный поток от исключительного потока и позволить исключениям пузыриться до уровня, где они могут обрабатываться наиболее подходящим образом. Итак, как уже указывали многие, это зависит от того, является ли провал действительно исключительным или нет.

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

Если вам нужно знать количество строк, на которые влияют, то вы должны использовать версию A. Если вам не нужно, то вы можете использовать версию B - но любое преимущество, которое вы могли бы получить с точки зрения меньших усилий по написанию кода, уже пропало Вы потрудились опубликовать обе версии на онлайн-форуме!

Моя точка зрения такова: какое решение лучше, полностью зависит от ваших требований к данному приложению, и вы знаете эти обстоятельства гораздо лучше, чем мы. Не существует общеотраслевого, безопасного в использовании, наилучшего практического решения, которое не будет уволено из-за него, что лучше в целом ; Вы должны думать об этом сами. И для решения, столь же легко пересмотренного, как и это, вам не нужно тратить столько времени на размышления.

Двумя важнейшими принципами разработки программного обеспечения для сопровождения являются KISS и YAGNI .

• ПОЦЕЛУЙ : будь проще, глупый
• ЯГНИ : Тебе это не нужно

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

Любая сложность, которую вы добавляете в программу, платная в течение длительного периода времени. Программа становится более трудной для чтения, более сложной для изменения и более легкой для выявления ошибок. Не попадайтесь в ловушку добавления вещей «на всякий случай». Это ложное чувство безопасности.

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

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

Целые строки или статус ошибки

Подумайте о возврате целых строк, по крайней мере, во время выполнения. При вставке в БД вам может понадобиться проверить данные, которые были вставлены - поскольку они часто будут отличаться от того, что вы отправили в БД; К распространенным примерам относятся автоматически сгенерированные идентификаторы строк (которые, скорее всего, понадобятся приложению), значения по умолчанию, определяемые БД, и результаты триггеров, если вы их используете.

С другой стороны, если вам не нужен возвращаемые данные, то вы также не нужны пораженное количество строк, так как это не полезно для результата 0. Если есть ошибки, то вам необходимо вернуть , какой из ошибка произошла, в соответствии с принципами обработки ошибок вашего проекта (исключения, числовые коды ошибок и т. д.); но есть допустимые запросы, которые будут корректно влиять на 0 строк (т.е. «удалить все просроченные ордера», если их на самом деле нет).