2009-02-05 60 views
7

我從事大多數職業生涯中的單線程業務邏輯/後端編程工作。我現在想學習網絡編程,但想知道網絡編程與非GUI編程(例如編寫API或文件處理應用程序)的不同之處。我不是在談論GUI設計方面(有人已經問過這個問題here),而是關於編程複雜性。當我在一個Web應用程序上工作的時候,我覺得Web應用程序相對而言是非確定性和不可預知的(例如,由於事件驅動的Web應用程序的多線程模型,事件和行動的幾個排列和組合,需要照顧)。網絡編程與後端編程有什麼不同?

你會說什麼是網絡編程的一些基本功能,使它不同於非GUI應用程序?後端開發人員在Web應用程序上工作時可能犯的錯誤是什麼?

編輯 我的後臺編程的定義是指非GUI應用程序,如一個API或分析大量數據文件的文件處理批處理應用程序,讀取記錄,做了很多的數字運算的計算上的數據並將結果輸出到另一個文件或數據庫中。另一個例子可能是一個日期和時間實用程序庫。

+0

我不明白你與「後端編程」的關係。您是否想區分「桌面」和「網絡」開發? – 2009-02-05 02:55:48

+0

不,我想區分「非GUI編程」和「網絡編程」。參見編輯。 – Rahul 2009-02-05 03:38:24

+0

@Rahul,你會認爲控制檯應用程序是「後端」,因爲他們沒有GUI? – 2009-02-23 15:23:59

回答

8

Web應用程序通常感覺像單線程應用程序,因爲您 - 應用程序開發人員 - 很少創建自己的線程。如果有的話,它實際上更容易一些,因爲Web事務的無狀態性意味着您必須每次從數據庫加載頁面的數據。因此,您不必擔心併發性,因爲「無論哪裏」通常都足夠好。

Web開發最大的問題是你必須隨着時間積累的所有背景知識。你如何佈置網頁?你如何用CSS來設計風格?你如何從查詢字符串中獲取參數?你如何驗證JavaScript中的字段值?所有這些事實際上都很容易學習,但其中只有很多這樣的東西,它可能是一個真正的痛苦。

9

網絡編程最大的挑戰是處理狀態。 HTTP是一種無狀態協議。這可能會使維護狀態比桌面應用程序更具挑戰性。由於這個原因,Web應用程序往往會有不同的生命週期。每個Web開發平臺的處理方式都有所不同,但他們都需要以某種方式處理它。

+0

很多桌面應用程序都使用HTTP。 – 2009-02-05 02:53:49

+0

是的,所以那些桌面應用程序是Jim Petkus正在談論的受益者。 – 2009-02-05 02:56:08

+0

同意。 HTTP的無狀態是最糟糕的事情。 – 2009-02-05 02:58:16

1

大多數網站也有一個後端組件。典型的結構是這樣的:

  1. UI - HTML/CSS/JavaScript的
  2. 控制器 - 如果使用MVC
  3. 業務邏輯/服務 - 這是後端
  4. 數據庫 - 這也是後端

所以建設網站仍然意味着很多後端工作。至於用戶界面方面,主要的區別是你需要對設計和佈局有很好的關注才能做得好。 html/css技術本身非常簡單。

1

HTML實際上是爲提供物理論文而開發的。您仍然可以在一些舊的元標記中看到它。無論如何,差別在於網絡編程是無狀態的,而厚客戶端開發則不是。

正如你熟練地指出的,它的一切都是由事件驅動的。真正的JavaScript通過創造一個有狀態的環境的幻想有點破壞了Web開發,但最終一切都歸結爲簡單的HTML。它開始學習永遠不會太晚,我會說開始製作一些靜態HTML頁面,並移動到MVC框架,我建議微軟MVC框架。它非常棒,還有其他的你可以像ASP.Net Webforms一樣使用,但是你不會通過將東西拖放到設計器上來學習任何東西;)。

3

我親眼目睹的最大缺陷應用程序開發人員在進入Web時並未考慮其代碼成本。要麼他們濫用MySQL以至於陷入困境,他們會編寫使用太多內存的代碼,或者使前端頁面大到適合撥號/手機或低端寬帶/ dsl管道。

有時在編寫一個繁重的頁面時不能避免,但是可以考慮嘗試緩存或儘可能多地嘗試緩存,或者在編寫將會受到很大打擊的頁面時,他們將不會努力進行配置和在他們出門之前優化查詢。

這並不是說這些人很愚蠢,只是缺乏經驗和認識,他們需要發揮很好,編寫代碼有點精簡。

0

Web編程不是後端編程。它顯示前端,網絡上的東西。

否定義嗎?

編輯

Web編程拉你到一貫呈現的數據,直觀,給大家。後端編碼意味着構建該數據,以與呈現相同的方式,但不呈現它。

2

後端編程比網頁編程要容易得多。 (你已經被警告!)網絡編程是最容易展示給每個人的。

0

另一個考慮是根據您的定義進行後端編程更容易測試。

一旦你開始網絡編程你在不同的瀏覽器的不同相同的代碼的解釋的擺佈。此外,使用鼠標和鍵盤輸入的用戶可以通過多種方式來打破您的生產。

1

網絡& GUI應用程序與人類接口。與服務和數據庫後端應用程序接口。由於這樣的規範需要包括你的用戶的心理模型的顯著考慮 - 使事情表現爲人們期望他們。做到這一點 - 瞭解用戶的想法 - 並非總是那麼簡單或合乎邏輯。您可能擁有優雅的算法解決方案,但卻無法參與,因爲人們並不總是在邏輯上思考。很多時候,很優雅的UI的是極其扭曲的編碼明智..這是很違背系統 - >系統編程

根據問題的空間,這在很大程度上可能是藝術多於科學。

1

一個考慮(其中包括許多)與Web編程的是,用戶將不僅是愚蠢的(這並不是說他們都是,但你總要因素,在),他們有時會(假設總是)是徹頭徹尾的惡意討厭的,並會盡他們的一切力量來摧毀你的應用程序,你的數據庫,你的週末,你的理智...

在企鵝射擊時,會像一個非常小的修女一樣偏執。不要相信你的用戶。

0

根據您對「後端編程」的定義,您的問題不僅適用於Web應用程序,還適用於任何GUI應用程序。

這種類型取決於我們所談論的是什麼樣的GUI應用程序。例如:

  • 內部業務應用程序傾向於涉及大量業務流程工作流邏輯,記錄保存以及單獨系統之間的互操作性。不需要花哨的算法或數字運算。你的受衆是有限的,所以性能不是什麼大問題,但跨平臺兼容性很重要,所以這些往往是Web應用程序。您主要關心的是如何輕鬆將業務系統連接在一起,並保持API分層以確保GUI代碼不必處理任何業務邏輯代碼。
  • 公共網站(比如這個)往往涉及較少的正式架構,更多的是「只是讓這個很酷的功能工作,所以我們可以獲得更多的訪問者」的心態。再次,除非性能是一個問題,否則不需要數字運算或算法。性能對於像Slashdot或谷歌這樣的大型網站來說更是一個問題,所以如果您預計的是快速增長,那麼可以提前設計可擴展性。
  • 公共電子商務網站類似於上述兩種:功能和性能非常重要,但同樣重要的是它下面的結構化體系結構,它將所有商業業務系統(購買,供應商,購物車,支付網關等)

對於實際的GUI部分,應用程序類型的複雜性決定了GUI代碼的複雜程度。對於需求經常變化的高度複雜,嵌套的GUI,很容易陷入將太多GUI內容放入一個頁面的陷阱中。很快頁面超出了大多數人的複雜度閾值,使得頁面難以維護。預先考慮如何將GUI的不同部分劃分爲不同的組件,然後將它們連接在一起,這是值得的。如果您不熟悉GUI編程,請閱讀關於模型 - 視圖 - 控制器(MVC)模式的一些文章。

對於簡單的網站來說,大多數網頁都是相當靜態的,這個問題並沒有那麼多,因爲每個單獨的網頁都很容易維護。

0

大部分的網絡編程都是在70年代初流行的風格中完成的,在Dijkstra的「goto被認爲是有害的」之前是衆所周知的。