Множество платформ, одна и та же базовая кодовая база, лучшая стратегия?
Я разрабатываю небольшое веб-приложение. Здесь нет никакой расширенной функциональности, только базовые запросы из базы данных.
Сам веб-сайт позволяет входить в систему обычными способами и подключаться к Facebook, затем он имеет некоторую функциональность CRUD.
Я буду создавать для него "родное" приложение Facebook, а также приложение для iPhone и приложение для Android.
Мой вопрос в том, как лучше всего поддерживать кодовую базу?
Я делал это раньше, когда создавал базовый API, который позволял мне добавлять, редактировать и удалять записи базы данных, а затем я использовал HTTP-сообщения для API на всех платформах. Это чрезвычайно упростило обслуживание базы кода, исправление ошибок, внесение обновлений и т. Д., Так как мне нужно было обновить только одно место. Сами отдельные приложения действительно имели только некоторую очистку, а затем некоторые запросы на завиток. Хотя это отлично работало для мобильных приложений (iPhone и Android), оно действительно делало ненужные http-запросы на веб-сайте и в приложении Facebook.
Что такое как лучше всего подойти к этой ситуации? Должен ли я создать 2 веб-сайта (Facebook и обычный веб-сайт) и API? Это сделало бы его более сложным в обслуживании, но гораздо более стабильным и быстрым. Просто API, который облегчил бы его обслуживание?
Кодовая база - это PHP в CodeIgniter с MySQL в качестве базы данных.
5 answers
Я думаю, вам следует создать 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]);
Очевидно, вам захочется найти API Obj-C для кодирования/декодирования JSON. Я использую touchjson
Мы используем Kohana с января. Мы переехали из Codeigniter, и это довольно мило. Каскадная файловая система упрощает организацию вашего кода.
Примером использования нескольких платформ является Android. Мы перенесли большую часть логики в php, затем перенесли ее в веб-представление Android с некоторыми помощниками для подключения и скорости, и оно отображается как родное приложение.
С помощью Kohana просто создайте представление JSON для вызовов API. Вы можете проверить запрос, чтобы узнать, есть ли это AJAX, чтобы решить, использовать ли JSON или другое представление.
Чтобы выбрать между браузером или мобильным приложением, мы устанавливаем строку агента пользователя, уникальную для нашего мобильного приложения, а затем тестируем ее на стороне php. Кроме того, у нас есть иерархия представлений, которая позволяет нам иметь несколько разных файлов макета. Есть один для мобильных запросов, один для веб-приложения, один для определенного типа пользователей и т.д.
В целом, Kohana более гибкая, чем Codeigniter, и является отличной базой для создания веб-приложения и API вкл.
Недостатком Коханы является то, что документация довольно плохая. Однако, как только вы начнете его использовать, вы быстро поймете это. Кодовая база является чистой и легко читаемой.
Извините, если я слишком много говорил о Кохане, но, если вы хотите использовать php и обладать гибкостью, которой вы, кажется, жаждете, это место для начала, ИМХО.
Я бы выбрал N-уровневый подход. Относитесь к "мобильным" приложениям (iOS и Facebook) как к приложениям самого высокого уровня. Они тратят большую часть своего времени на отображение данных и получение информации от пользователя. Благодаря здоровой дозе AJAX они работают с приложением PHP, которое служит "Контроллером", обрабатывающим бизнес-логику и занимающимся сохранением и параллелизмом. Да, вокруг летает много данных, но не оптимизируйте преждевременно. Разрабатывая свое приложение, подумайте о том, где вы можете кэшировать данные, и как вы находите избыточные запросы, оптимизируйте их в более поздних версиях. К сожалению, на самом деле нет менеджера отношений сущностей, который пересекает границу Javascript/PHP, так что на некоторое время он принадлежит вам.
Я создал несколько проектов, подобных тому, который вы описываете. Та же платформа, codeigniter и MySQL, что в данном случае не имеет большого значения. Одна вещь, которую я нашел полезной до сих пор, заключается в том, что когда ваш веб-сайт просматривается из iframe facebook, пользовательский агент, попадающий на ваш сайт,
'facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)'
Чтобы вы могли его обнаружить.
Иногда вам может сойти с рук простое изменение css-файла на основе агента пользователя, если вам не нужна аутентификация. Если вам нужна аутентификация, просто напишите отдельный контроллер для него или используйте js SDK. Если этого недостаточно или ваш сайт более сложный, создайте отдельные представления для facebook и обычного веб-сайта и переключайте их в соответствии с агентом пользователя. Не могу помочь вам с API, но я полагаю, что вы будете использовать те же модели для API, что и для веб-сайта, отдельный контроллер необходим.
Немного подумав, вы можете получить API без особых дополнительных усилий, особенно если и он, и ваш веб-сайт построены на принципах REST. Например, если у вас есть метод "добавить" в контроллере, это будет делать почти то же самое как для веб-сайта, так и для API. Если вы настроили дерево данных (с массивами или объектами) для передачи в представление, вы можете просто вернуть представление этого дерева в кодировке JSON, если запрос выполняется через API.
Что касается приложение Facebook, в зависимости от того, насколько оно имеет общее с основным веб-сайтом, вы можете создать оба сайта на одной и той же установке codeigniter с помощью магии маршрутизации и/или перезаписи URL-адресов, позволяя вам использовать любые общие модели, контроллеры или аналогичные представления, если вы используете расширяемую библиотеку шаблонов.