许多平台，相同的核心代码库，最佳策略？答案

【问题标题】：Lots of platforms, same core codebase, best strategy?许多平台，相同的核心代码库，最佳策略？
【发布时间】：2011-08-19 06:01:01
【问题描述】：

我正在开发一个小型网络应用程序。没有任何高级功能，只是来自数据库的基本查询。

网站本身允许通过常规方式和 Facebook Connect 登录，然后它具有一些 CRUD 功能。

我将为它创建一个“原生”Facebook 应用程序，以及一个 iPhone 应用程序和一个 Android 应用程序。

我的问题是，维护代码库的最佳方式是什么？

我之前已经这样做了，我创建了一个允许我添加、编辑和删除数据库记录的基本 API，然后我在所有平台上使用 HTTP POST 到 API。这使得维护代码库、修复错误、进行更新等变得非常容易，因为我只需要更新一个地方。各个应用程序本身实际上只有一些皮肤，然后是一些 cURL 请求。虽然这对移动应用程序（iPhone 和 Android）非常有效，但它确实在网站和 Facebook 应用程序上发出了不必要的 http 请求。

处理这种情况的最佳方法是什么？我应该创建 2 个网站（Facebook 和普通网站）和一个 API 吗？这将使其更难以维护，但更稳定和更快。只是一个 API，可以很容易维护吗？

代码库是CodeIgniter中的PHP，以MySQL为数据库。

【问题讨论】：

我完全不明白你在问什么。您说您以前做过相同（或类似）的网络，并且维护它非常简单，那为什么还要问呢？你为什么不再次使用同样的方法？？？
我提到它很容易维护，但是它创建了很多不必要的http请求。正如任何人都会告诉您的那样，当您查询同一台机器时，这是一种非常落后的数据传递方式。这就像给隔壁邻居寄信而不是自己送信一样。
我刚刚用简单的 API（类似于 XML-RPC）和一个 android 应用程序构建了一个网站。网站有自己的前端和后端（管理），API 仅用于通信目的（与 android 和 iphone 应用程序通信）。而且我认为这种方法没有什么不好...只有一个缺点-当数据库更改时（出于某种原因），我必须更新在其上方运行的前端+后端 PHP 部分、API 和 android 应用程序。但无论如何你都不会保留一半......

标签： php mysql facebook api codeigniter

【解决方案1】：

我已经创建了几个项目，就像你描述的那样。相同的平台，codeigniter 和 MySQL，在这种情况下差别不大。到目前为止，我发现有用的一件事是，当从 facebook iframe 查看您的网站时，访问您网站的用户代理是

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

这样你就可以检测到它。

如果您不需要身份验证，有时您只需根据用户代理更改 css 文件即可。如果需要认证，只需要为它写一个单独的控制器，或者使用js SDK。如果这还不够，或者您的网站更复杂，请为 facebook 和普通网站设置单独的视图，并根据用户代理进行切换。无法帮助您使用 API，但我想您将使用与网站相同的 API 模型，单独的控制器是必须的。

【讨论】：

所以你会建议所有东西都使用相同的代码库，API 使用不同的控制器，Facebook 使用不同的模板？我猜是有道理的，可能需要在 CodeIgniter 中更好地分离文件。我知道您可以将文件夹拆分为：/login/controllers|models|views/ 而不是 /controllers|models|views/login/，这可能有用
嗯，简而言之，是的。在过去的一年里，我一直只在做 facebook 编程，所以我的思绪立刻就去了那里。通常发生在我身上的是我最终得到一个大模型文件，以及一次性的、尽可能短的控制器和视图。此外，如果您打算将其维护一年以上，请尽可能将 facebook 部分分开，因为它们经常更改。祝你好运

【解决方案2】：

只要稍加考虑，您就可以通过很少的额外工作获得一个 API，特别是如果它和您的网站都是围绕 REST 原则构建的。例如，如果您在控制器中有一个“添加”方法，这将对网站和 API 执行几乎完全相同的操作。如果您设置了一个数据树（带有数组或对象）以传递给视图，并且如果请求是通过 API 发出的，那么您可以只返回该树的 JSON 编码表示。

至于 Facebook 应用程序，取决于它与主网站有多少共同点，您可以在同一个 codeigniter 安装上构建两个站点，并使用一些路由和/或 URL 重写魔法，让您共享任何通用模型、控制器或如果您使用的是可扩展的模板库，则可以看到类似的视图。

【讨论】：

【解决方案3】：

我认为你应该创建一个带有 php 类的 API，然后用一个 HTTP API 包裹它。

PHP 类 API：

<?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]);

显然，您会希望找到一个用于编码/解码 JSON 的 Obj-C API。我正在使用TouchJSON

【讨论】：

【解决方案4】：

我们从一月份就开始使用 Kohana。我们从 Codeigniter 搬来了，它非常可爱。级联文件系统使组织代码变得容易。

多平台使用的一个例子是 Android。我们已将大部分逻辑推送到 php 中，然后将其拉入 Android WebView，并带有一些连接和速度帮助器，它的显示就像一个原生应用程序。

使用 Kohana，只需为 API 调用创建 JSON 视图。你可以检查请求是否是AJAX来决定是使用JSON还是其他视图。

为了在浏览器或移动应用程序之间做出决定，我们为我们的移动应用程序设置了一个唯一的用户代理字符串，然后在 php 端对其进行测试。此外，我们有一个视图层次结构，可以让我们拥有一些不同的布局文件。有一个用于移动请求，一个用于 Web 应用程序，一个用于特定类型的用户，等等。

总体而言，Kohana 比 Codeigniter 更灵活，并且是构建 Web 应用程序和 API 的良好基础。

Kohana 的缺点是文档很差。但是，一旦开始使用它，您就会很快理解它。代码库干净且易于阅读。

抱歉，如果我对 Kohana 进行了太多介绍，但是，如果您想使用 php 并拥有您似乎渴望的灵活性，那么这是开始的地方，恕我直言。

【讨论】：

他已经提到他正在使用 CI——我建议不要随意跳船，尽管出于灵活性的原因我确实从 CI 搬到了 Kohana。在过去的几个月里，Kohana 的文档有了很大的改进，而对 Kohana 的批评越来越少。

【解决方案5】：

我会采用 N 层方法。将“移动”（iOS 和 Facebook）应用程序视为最高级别。他们大部分时间都在显示数据和从用户那里获取输入。通过健康剂量的 AJAX，他们与 PHP 应用程序一起工作，PHP 应用程序充当处理业务逻辑和处理持久性和并发性的“控制器”。是的，有很多数据飞来飞去，但不要过早优化。当你开发你的应用程序时，想想你可以在哪里缓存数据，当你发现过多的请求时，在以后的版本中进行优化。不幸的是，实际上没有跨越 Javascript/PHP 边界的实体关系管理器，所以它暂时是由你自己拥有的。

【讨论】：