許多平臺，相同的核心代碼庫，最佳策略？

我正在開發一個小型的網絡應用程序。沒有任何高級功能，只有來自數據庫的基本查詢。許多平臺，相同的核心代碼庫，最佳策略？

該網站本身允許通過通常的方式和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

許多平臺，相同的核心代碼庫，最佳策略？

回答

相關問題