Создание API, который быстр

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

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

В этом случае все это зависит от индексов таблицы. Мы используем SQL-сервер 2000 для 24/7 приложения, которое обрабатывает по 100K финансовым транзакциям в день. Самая большая/основная таблица имеет более чем 100 миллионов строк, и 15 индексов (масса удаляет, не довольно возможны, если время работы желаемо). Даже при том, что весь SQL сделан в Хранимых процедурах, мы не используем триггеры или внешние ключи из-за хита производительности.

53
задан Reyan Chougle 3 August 2019 в 02:50
поделиться

6 ответов

Эта статья объясняет это намного лучше, чем я когда-либо мог.

РЕДАКТИРОВАТЬ, не могу втиснуть это в комментарий ...

у интерфейсов есть две стороны, реализация и использование. Я согласен с тем, что со стороны создания нужно проделать еще больше работы, однако основные преимущества можно найти на стороне использования. На самом деле, для меня главное преимущество плавных интерфейсов - это более естественный, легкий для запоминания и использования, а почему бы и нет, более эстетичный API. И, может быть, попытка сжать API в свободной форме может привести к более продуманному API?

Как говорит Мартин Фаулер в оригинальной статье о свободных интерфейсах :

Вероятно, самая важная вещь для обратите внимание на этот стиль, что намерение сделать что-то в линии внутреннего DomainSpecificLanguage. Действительно это почему мы выбрали термин «свободно», чтобы описать это, во многом эти два термины являются синонимами. API есть в первую очередь предназначен для чтения и течь. Цена этого свободного владения больше усилий, как в мышлении, так и в сама конструкция API. В простой API конструктора, установщика и методы сложения намного проще написать. Придумывая хороший беглый API требует хороших размышлений.

Поскольку в большинстве случаев API создаются один раз и используются снова и снова, дополнительные усилия могут того стоить.

И подробный? Я за многословие, если оно служит удобочитаемости программы.

44
ответ дан 7 November 2019 в 08:30
поделиться

KISS: Держите это простым идиотским.

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

Даже если вы думаете, что «каждый может использовать этот API, потому что он использует все разные типы методологий». По правде говоря, пользователь начнет чувствовать себя потерянным из-за того, что вы постоянно меняете структуру / структуру данных API в соответствии с новым принципом проектирования или соглашением об именах.

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

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

6
ответ дан 7 November 2019 в 08:30
поделиться

Нет и да. Основы - это хороший интерфейс или интерфейсы для тех типов, с которыми вы хотите работать плавно. Библиотеки с методами расширения могут расширить это поведение и вернуть интерфейс. Методы расширения дают другим возможность расширить ваш свободный API с помощью большего количества методов.

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

Изучение создания свободного API делает это путем просмотра существующих API. Сравните FluentNHibernate с плавными интерфейсами .NET API или плавными интерфейсами ICriteria. Многие API-интерфейсы конфигурации также разработаны "свободно".

0
ответ дан 7 November 2019 в 08:30
поделиться

Что такое свободный API

Википедия определяет их здесь http://en.wikipedia.org/wiki/Fluent_interface

Почему не использовать свободный интерфейс

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

Другой вариант, ничего не делать!

Ничего не реализовывать. Не предоставляйте «простых» конструкторов для установки свойств и не предоставляйте умный интерфейс, который поможет вашему клиенту. Разрешите клиенту устанавливать свойства, как обычно. В .Net C # или VB это может быть так же просто, как использование инициализаторов объектов .

Car myCar = new Car { Name = "Chevrolet Corvette", Color = Color.Yellow };

Таким образом, вам не нужно создавать какой-либо умный интерфейс в вашем коде, и это очень удобно для чтения.

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

CarConfig conf = new CarConfig { Color = Color.Yellow, Fabric = Fabric.Leather };
Car myCar = new Car { Config = conf };
5
ответ дан 7 November 2019 в 08:30
поделиться

MrBlah,

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

Ниже вы увидите пример кода, который я создал в другом потоке

public class Coffee
{
    private bool _cream;
    private int _ounces;

    public static Coffee Make { get { return new Coffee(); } }

    public Coffee WithCream()
    {
        _cream = true;
        return this;
    }
    public Coffee WithOuncesToServe(int ounces)
    {
        _ounces = ounces;
        return this;
    }
}

var myMorningCoffee = Coffee.Make.WithCream().WithOuncesToServe(16);
36
ответ дан 7 November 2019 в 08:30
поделиться

с беглым API:

myCar.SetColor(Color.Blue).SetName("Aston Martin");

Проверьте это видео http://www.viddler.com/explore/dcazzulino/videos/8/

1
ответ дан 7 November 2019 в 08:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: