Пойти API или не [закрытый]
В то время как BennyBechDk мог бы быть на правильном пути, у меня есть несколько проблем с его кодом, который я собираюсь исправить ниже:
uses Classes, XMLIntf, xmlDoc, SysUtils;
function IsValidXMLDoc(aXmlDoc: IXMLDocument): boolean;
var
validateDoc: IXMLDocument;
begin
result := false; // eliminate any sense of doubt, it starts false period.
validateDoc := TXMLDocument.Create(nil);
try
validateDoc.ParseOptions := [poResolveExternals, poValidateOnParse];
validateDoc.XML := aXmlDoc.XML;
validateDoc.Active := true;
Result := True;
except
// for this example, I am going to eat the exception, normally this
// exception should be handled and the message saved to display to
// the user.
end;
end;
, Если Вы хотели, чтобы система просто повысила исключение, тогда нет никакой причины сделать его функцией во-первых.
uses Classes, XMLIntf, XMLDoc, SysUtils;
procedure ValidateXMLDoc(aXmlDoc: IXMLDocument);
var
validateDoc: IXMLDocument;
begin
validateDoc := TXMLDocument.Create(nil);
validateDoc.ParseOptions := [poResolveExternals, poValidateOnParse];
validateDoc.XML := aXmlDoc.XML;
validateDoc.Active := true;
end;
, поскольку validateDoc является интерфейсом, от него избавятся правильно, поскольку функция/процедура выходит, нет никакой потребности выполнить распоряжение самостоятельно. Если Вы называете ValidateXmlDoc и не получаете исключение тогда, это допустимо. Лично мне нравится первый вызов, IsValidXMLDoc, который возвращает true, если допустимый или ложный, если не (и не повышает исключения за пределами себя).
4 ответа
Я думаю, что можно многое сказать о последовательности. Если вы предоставляете API для своих клиентов, мне кажется, что, используя тот же API, вы лучше его поймете. поддерживая его для своих клиентов, вы будете регулярно тестировать его (помимо регрессионных тестов), и вы отправляете сообщение о том, что он достаточно хорош для вас, поэтому он должен подойти вашим клиентам.
Скрывая все, что стоит за API, вы можете изменять представления базы данных и не должны изменять как код интерфейса API (для представления данных через API), так и код доступа к базе данных в ваших собственных приложениях . Вы бы изменили только первое.
Наконец, на такие вопросы производительности действительно можно ответить, только попробовав и измерив. Возможно, это '
Я бы определенно пошел по маршруту API. Это обеспечивает простой в обслуживании интерфейс для ВСЕХ приложений, которые будут взаимодействовать с вашим приложением, включая проверку и т. Д. Конечно, вы можете обеспечить целостность базы данных с помощью ограничений столбцов и хранимых процедур, но зачем поддерживать и это?
Не забывайте - вы также можете кэшировать вызовы API в файловой системе, памяти или с помощью memcached (или любой другой службы). Если наборы данных не изменились (проверьте с помощью updated_at или etags), вы можете просто вернуть кешированные версии для значительного повышения скорости. Добавление etags в последнее приложение, которое я разработал, привело к тому, что время загрузки HTML увеличилось с 1,6 секунды до 60 мс.
Не по теме: Идея, с которой я играл, - это динамическая загрузка версий API в зависимости от запроса. Что-то вроде этого даст вам возможность кардинально изменить API, сохранив при этом обратную совместимость. Поскольку разные версии находятся в отдельных файлах, их будет просто поддерживать по отдельности.
Также, если вы используете Api внутри, вы сможете уменьшить объем кода, который вам нужно поддерживать, так как вы будете поддерживать только API, а не API и свои собственные внутренние методы. для доступа к данным.
Я думал об одном и том же в отношении проекта, который собираюсь начать, независимо от того, должен ли я создавать свое приложение Rails с нуля в качестве клиента API или нет. Я согласен с уже упомянутыми здесь преимуществами, которые я резюмирую и добавлю к:
- Улучшенный дизайн API: Вы становитесь пользователем своего API, поэтому, когда вы решите его открыть, он станет намного более совершенным. ;
- Независимость от базы данных: с уменьшенной связью вы могли позже переключиться с СУБД на Хранилище документов без значительных изменений;
- Сопоставимая производительность: Производительность можно решить с помощью кэширования HTTP (хотя я ' Я хотел бы увидеть некоторые числа, сравнивающие оба).
Вдобавок к этому вы также получаете:
- Лучшая тестируемость: вся ваша бизнес-логика тестируется черным ящиком с помощью базового запроса / ответа HTTP. Безголовые браузеры / Selenium становятся ответственными только за поведение, зависящее от приложения;
- Независимость от внешнего интерфейса: вы не только можете свободно изменять представление базы данных, но и можете изменять весь внешний интерфейс, начиная с ванильного Rails с -HTML-and-page-reloads, в разбрызганный-Ajax, в полноценный чистый javascript (например, с GWT ), все используют одну и ту же внутреннюю часть.
Критика
Одна проблема I Изначально я видел, что такой подход лишит меня всех удобств и гибкости, которые предоставляет ActiveRecord, с ассоциациями, named_scopes и всем остальным. Но использование API через ActveResource возвращает много хороших вещей, и кажется, что вы также можете иметь named_scopes . Не уверен насчет ассоциаций.
Больше критики, пожалуйста
Мы '