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

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

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

Я создам для него "родное" приложение для Facebook, а также приложение для iPhone и приложение для Android.

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

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

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

Кодовая база PHP в CodeIgniter с MySQL как база данных.

ОТВЕТЫ

Ответ 1

Я думаю, вам следует создать API с php-классами, а затем включить API-интерфейс HTTP.

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

чтобы вы могли его обнаружить.

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

Ответ 5

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

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