在.NET中使用Ruby或PHP

當前我們有一個用提供者自己的專有語言/框架編寫的Web應用程序。不幸的是，由於它的語法有限，「不可思議」的體系結構，它不適合使用。在.NET中使用Ruby或PHP

隨着一些非常出色的開發平臺（.NET，PHP，Ruby - 請注意，我對PHP或Ruby一無所知，但我聽說它們非常棒：p），我們想從web應用程序中抽象出來他們的數據訪問代碼，以便我們可以使用任何我們想要構建Web應用程序。

我向他們提出的是，他們給我們提供了一個使用通用開發語言編寫的服務層，然後我們可以在我們的應用程序中使用它。不幸的是我（作爲一個.net開發者）我不認爲他們會選擇在c＃中編寫它。

所以我的問題是這樣的，建議服務層寫入什麼。理想情況下，它應該是一個.net開發人員，我將能夠拿起，甚至更好地使用服務層的能力.net或php應用程序（我已閱讀了一些關於Ruby.NET的信息，所以相信這是可能的？）。我很快瀏覽Ruby on Rails和PHP，我會說Ruby對我更有吸引力（PHP似乎有點「scripty」，但是我知道什麼，我沒有用過它）。

經驗證可以聽到使用兩者的開發人員的聲音。

感謝本

來源

2010-02-11 Ben Foster

說Ruby和PHP很棒就像說甜食和菠菜很棒。 \ *呸\ *。 – 2010-02-11 10:15:13

我無法真正評論，因爲我對這兩方面都不夠了解。我敢肯定，任何開發者都會說他/她的選擇語言很好 - 儘管我可以肯定地說，這個討論的應用程序的供應商也是如此 - 事實並非如此。 – 2010-02-11 14:55:52

感謝您的回覆。 SOAP/REST api肯定會給我們提供我們所需的靈活性，並且不會把我們壓在一個特定的開發平臺上。我們已經討論過使用像Sonic這樣的ESB解決方案來進行另一個項目，所以希望供應商可以利用它來提供SOAP API。 – 2010-02-11 15:12:02

爲什麼不使用HTTP作爲你的界面？由於他們已經有了某種Web基礎設施，所以這應該很簡單 - 將接口描述爲一組可以發送到和從中獲取的URL。對於這條路線，請在互聯網上查找關於REST和RESTful架構的所有文章。

然後，退後一步。不要讓狂熱分子殺死你的精神。只需使界面工作，不必過於擔心純粹的REST（儘管建議通常是合理的）。

這種方法爲您在編寫網頁時提供了相當大的靈活性。

這樣，服務層使用哪種語言並不重要：您感興趣的所有內容都是用於訪問服務層的接口。其他選項將爲他們提供一個接口（帶點運氣，可以很容易地被.NET使用）或一個接口（不知道如何在.NET中使用）。

我的觀點是：你不應該聽寫服務層寫入的語言。你應該聽寫服務層公開的接口 - 然後用你選擇的語言消費。

來源

2010-02-11 10:17:42

這個問題似乎在詢問實現技術而不是接口設計。「使用HTTP作爲你的接口」當然是合理的建議，但無助於確定「建議服務層寫入的內容是什麼」。 – itowlson 2010-02-11 10:28:13

的確如此，但我的觀點是，這並不重要 - 它們應該只保留服務層的（專有）語言，他們已經在使用... – 2010-02-11 13:03:36

關於提到的語言。 PHP和Ruby都被解釋爲「腳本語言」，就這一點而言，它們是Perl，Python和其他許多語言。如果其他人用於通用計算，則PHP更加專注於Web開發。

似乎有一個PHP compiler爲.Net，但它可能沒有積極的發展。網站上的最新消息是2008年3月。我沒有這方面的經驗（並且實際上並不太喜歡PHP，TBH）。

IronRuby現在在v1.0 RC2，並且正在積極地由微軟開發。它運行良好並與.Net框架愉快地交互。從語法上講，它是Ruby 1.8.x的一個實現，並且足夠兼容以便能夠運行廣泛使用的Ruby on Rails Web框架，這是對Ruby實現合規性的相當密集的測試。從C＃開發人員的角度來看，元編程和所有的東西都是--這是一個真正的對象可能需要一段時間才能沉入其中。我認爲這是值得的。

然而，要求你的提供者在Ruby中編寫一個接口可能不是一個好主意 - 做得很好，並且採用「Rubyish」風格可能是他們不願意做的投資。消費類似Web API的東西對於Ruby來說是非常合適的目的，我認爲它比C＃運行速度要慢（在C＃中運行會比較慢），在網絡延遲等因素可能會出現的情況下，這並不重要主要貢獻者的總時間。我認爲這種類型的Ruby應用程序可能更便宜且更快創建和維護的可能性很大。

來源

2010-02-11 10:43:18

在.NET中使用Ruby或PHP

回答

相關問題