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

我正在开发一个小型的网络应用程序。没有任何高级功能，只有来自数据库的基本查询。许多平台，相同的核心代码库，最佳策略？

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

我会为它创造一个“天然”的Facebook应用程序，藏汉作为一个iPhone应用和Android应用程序。

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

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

解决这种情况的最佳方法是什么？我应该创建2个网站（Facebook和普通网站）和API吗？这会使维护更加困难，但更稳定和更快。只需一个API，这将使其易于维护？

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

来源

2011-05-05 Mike

我完全不明白你在问什么。你说过，你之前做过同样的（或同类）网站，维护它很简单，所以为什么再问一次？你为什么不再使用相同的方法？ – shadyyx 2011-05-05 10:10:46

我提到它很容易维护，但它创建了大量不必要的http请求。正如任何人会告诉你的，当你查询同一台机器时，这是一种非常倒退的方式。这就像给你的邻居发了一封信，而不是自己发送。 – Mike 2011-05-05 10:16:01

我刚刚用简单的API（与XML-RPC相似的东西）和一个android应用程序构建了一个网站。网站有自己的前端和后端（管理），API旁边仅用于交流目的（与android和iphone应用程序通信）。我没有看到这种方法没有什么坏处......只有一个骗局 - 当数据库发生变化时（出于某种原因），我必须更新在其上面运行的前端+后端PHP部分，以及API和Android应用程序。但是，无论如何，你不会保留一半... – shadyyx 2011-05-05 10:24:34

我认为你应该用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

来源

2011-05-08 23:34:57

我创建了一些类似于您所描述的项目。相同的平台，codeigniter和MySQL，在这种情况下几乎没有什么区别。有一件事，我发现有用到目前为止是，当你的网站从Facebook的IFRAME观看，用户代理打你的网站是

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

，所以你可以检测到它。

有时你可以逃脱只是改变基于用户代理的CSS文件，如果你不需要认证。如果你需要认证，只需为它编写一个单独的控制器，或者使用js SDK。如果这还不够，或者您的网站比较复杂，请为facebook和普通网站分别提供视图，并根据用户代理进行切换。无法帮助您使用API，但我想象您将为API使用与网站相同的模型，单独的控制器是必须的。

来源

2011-05-05 12:35:23 DannyKK

因此，你会建议使用相同的代码库来处理所有事情，使用不同的API控制器和Facebook的不同模板？我猜想是有道理的，可能必须考虑更好地分离CodeIgniter内的文件。我知道你可以将这些文件夹拆分成：/ login/controllers | models | views /而不是/ controllers | models | views/login /，这可能很有用 – Mike 2011-05-05 15:22:28

嗯，简而言之，是的。过去一年我一直只做Facebook编程，所以我的思想马上就到了那里。通常发生在我身上的是一个大型模型文件，一次性，尽可能短的控制器和视图。此外，如果您计划保持这一段时间更长一年，请尽可能分离Facebook部分，因为它们经常发生变化。祝你好运 – DannyKK 2011-05-05 22:07:24

随着一点点的深谋远虑，你可以得到一个API很少的额外的努力，特别是如果它和你的网站是围绕REST原则建立。例如，如果你在控制器中有一个“添加”方法，这对网站和API来说几乎完全一样。如果您设置了一个数据树（包含数组或对象）以传递给视图，那么如果通过API进行请求，则可以返回此树的JSON编码表示形式。

至于Facebook应用程序，取决于它与主网站有多少共同点，您可以在同一个代码化工具上安装一些路由和/或URL重写魔术的两个站点，让您可以共享任何常见模型，控制器，或者使用可扩展模板库的类似视图。

来源

2011-05-05 23:00:12 ZoFreX

自1月以来我们一直在使用Kohana。我们从Codeigniter搬来，很可爱。级联文件系统可以轻松组织您的代码。

多平台使用的一个例子是Android。我们已经将大部分逻辑推送到了php中，然后我们将其引入到Android WebView中，并使用一些助手来提供连接性和速度，并将其显示为本机应用程序。

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

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

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

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

对不起，如果我继续讲关于Kohana的话，但是，如果你想使用php并且具有你想要的灵活性，那么这是开始的地方，恕我直言。

来源

2011-05-19 04:45:32 Jonathan

他已经提到他正在使用CI-我会建议不要跳船，因为灵活性原因，我确实从CI转移到Kohana。 Kohana的文件在过去几个月里已经有了很大的改进，对Kohana的批评越来越少。 – 2011-05-19 05:02:12

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

来源

2011-05-19 04:53:17

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

回答

相关问题