Много платформ, одна и та же базовая кодовая база, лучшая стратегия?

Question

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

Сам сайт позволяет входить в систему с помощью обычных средств и Facebook Connect, а затем имеет некоторые функции CRUD.

Я буду создавать для него «нативное» приложение Facebook, а также приложение для iPhone и приложение для Android.

Мой вопрос: как лучше всего поддерживать кодовую базу?

Я делал это раньше, когда создал базовый API, который позволял мне добавлять, редактировать и удалять записи базы данных, а затем использовал HTTP POST для API на всех платформах. Это позволило чрезвычайно легко поддерживать кодовую базу, исправлять ошибки, делать обновления и т. Д., Поскольку мне нужно было обновить только одно место. Сами по себе отдельные приложения действительно имели некоторый скиннинг, а затем несколько запросов cURL. Хотя это отлично работает для мобильных приложений (iPhone и Android), на веб-сайте и в приложении Facebook выполняются ненужные http-запросы.

Как лучше всего подойти к этой ситуации? Должен ли я создать 2 сайта (Facebook и обычный сайт) и API? Это сделает его более сложным в обслуживании, но гораздо более стабильным и быстрым. Просто API, который бы облегчил поддержку?

База кода - это PHP в CodeIgniter с MySQL в качестве базы данных.

Answer 1

Я думаю, вы должны создать API с классами php, а затем обернуть вокруг него HTTP API.

API класса PHP:

<?php // myproducts.class.php

class MyProducts
{
  static function addProduct($name, $price)
  {
    // add the product
  }
}

А затем ваш HTTP API:

<?php // api/products.php

// read HTTP POST and decode it as json
$postParams = json_decode(file_get_contents('php://input'));
if (!$postParams)
  throw new exception("Could not decode POST data, invalid JSON.");

// run the desired action
$classMethod = $postParams['action'];
$arguments = $postParams['arguments'];
$result = call_user_func_array(array('MyProducts', $classMethod), $arguments);

// print result as JSON
print json_encode($result);

С этим вы можете легко написать класс obj-c для общения с HTTP API. Это может выглядеть примерно так:

NSData *postData = [@"{\"action\": \"addProduct\", \"arguments\": [\"Foo\", 42.00]}" dataUsingEncoding:NSUTF8StringEncoding];
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:API_URL cachePolicy:NSURLRequestReloadIgnoringLocalCacheData timeoutInterval:60];
[request setHTTPMethod:@"POST"];
[request setHTTPBody:postData];
NSHTTPURLResponse *urlResponse = nil;
NSError *error = nil;
NSData *responseData = [NSURLConnection sendSynchronousRequest:request returningResponse:&urlResponse error:&error];

NSLog(@"response: %@", [[[NSString alloc] initWithData:responseData encoding:NSUTF8StringEncoding] autorelease]);

Очевидно, что вы захотите найти Obj-C API для кодирования / декодирования JSON. Я использую TouchJSON

Answer 2

Я бы выбрал N-уровневый подход. Относитесь к «мобильным» (iOS и Facebook) приложениям как к наивысшему уровню. Они проводят большую часть своего времени, отображая данные и получая информацию от пользователя. Через большую порцию AJAX они работают с приложением PHP, которое служит «Контроллером» для обработки бизнес-логики и работы с постоянством и параллелизмом. Да, есть много данных, но не оптимизировать преждевременно. Разрабатывая свое приложение, подумайте о том, где вы можете кэшировать данные, и, когда вы обнаружите чрезмерные запросы, оптимизируйте работу в более поздних версиях. К сожалению, на самом деле не существует менеджера сущностных отношений, который пересекает границу Javascript / PHP, так что это ненадолго.

Answer 3

Мы используем Kohana с января.Мы переехали из Codeigniter, и это довольно мило.Каскадная файловая система упрощает организацию вашего кода.

Примером мультиплатформенного использования является Android.Мы внедрили большую часть логики в php, а затем добавили ее в Android WebView с некоторыми помощниками для обеспечения связи и скорости, и он отображается как собственное приложение.

С помощью Kohana просто создайте JSONпросмотр для вызовов API.Вы можете проверить запрос, чтобы узнать, будет ли это AJAX, чтобы решить, использовать ли JSON или другое представление.

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

В целом, Kohana более гибок, чем Codeigniter, и является отличной базой для создания веб-приложения и API на.

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

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

Answer 4

Немного подумав, вы можете получить API за очень небольшие дополнительные усилия, особенно если он и ваш сайт построены на принципах REST. Например, если у вас есть метод «добавить» в контроллере, это будет делать почти одно и то же как для веб-сайта, так и для API. Если вы настроили дерево данных (с массивами или объектами) для передачи в представление, вы можете просто вернуть JSON-кодированное представление этого дерева, если запрос выполняется через API.

Что касается приложения Facebook, то в зависимости от его общего с основным веб-сайтом вы можете создать оба сайта на одной и той же установке codeigniter с некоторой магией маршрутизации и / или перезаписи URL-адреса, что позволит вам использовать общие модели, контроллеры или аналогичные представления, если вы используете расширяемую библиотеку шаблонов.

Answer 5

Я создал несколько проектов, подобных описанному вами.Та же платформа, codeigniter и MySQL, что мало что меняет в этом случае.До сих пор я нашел полезным то, что при просмотре вашего веб-сайта из iframe в Facebook пользовательский агент, попадающий на ваш сайт, имеет значение

'facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)'

, поэтому вы можете его обнаружить.

ИногдаВы можете просто изменить файл CSS на основе пользовательского агента, если вам не нужна аутентификация.Если вам нужна аутентификация, просто напишите для нее отдельный контроллер или используйте js SDK.Если этого недостаточно или ваш сайт более сложный, создайте отдельные представления для Facebook и обычного веб-сайта и переключайте их в соответствии с пользовательским агентом.Не могу помочь с API, но я думаю, что вы будете использовать те же модели для API, что и для веб-сайта, отдельный контроллер является обязательным.