選擇哪種設計模式

我需要一個指向正確方向的指針。我一直在環顧四周，似乎找不到任何設計模式（GoF），這些模式將指向我正確的方向。選擇哪種設計模式

我開發一個小的數字標牌應用原型，那裏有一個簡單的服務器和連接到該服務器播放器應用程序（顯示圖像/視頻）的量。我的要求是能夠將100臺播放器連接到一臺服務器，並向每臺服務器分發50Mb數據。

我打算在服務器和玩家之間製作小型集線器（軟件集線器），集線器中的玩家（每個25個左右），讓集線器獲取並分發50Mb數據（分而治之，對吧？）。 50Mb僅適用於原型，我認爲在現實生活中，顯示視頻的距離應該大約爲300Mb。這些中心的原因是，我會避免100個玩家同時請求50Mb，而不是隻有4個（每個25個玩家）中心請求並重新分配。

當使用集線器，我將需要能夠四處移動玩家集線器之間，也就是從一個集線器刪除玩家並將其連接到另一個集線器。（是所有玩家連接我的想法一到同一集線器必須共享內容，所以輪轂將避免下載25級不同的電影）

請，沒有人知道這是如何在現實生活中做了什麼？您能否請我評論我的概念，並且/或者在模式/書本中指出我的正確方向，以幫助我解決這個問題。

來源

2010-09-01 Brian Hvarregaard

您需要退後一步。目前，您正試圖專注於軟件架構的細節，而未考慮（或至少提到）一些重要的要求。

它看起來像你真的只是想視頻流。所以：

您可以使用現成的視頻流產品嗎？這可能比建立自己的更便宜。

如果不是：

會爲你的廣播模式的工作，或者它必須是需求？也就是說，假設客戶端1請求視頻A，如果客戶端2在幾分鐘後還想要視頻A，那麼客戶端2是否成爲客戶端1正在接收的同一個視頻流的另一個觀衆，可以嗎？
這會不會在互聯網上提供，或在其上，你可以控制在專用網絡上？

如果您使用的是專用網絡和廣播模式將正常工作，您可以使用UDP多播，它可以提供比單純的按需解決方案顯著的帶寬減少。

因此，在開始決定軟件體系結構之前，您需要考慮硬件限制以及它們如何影響可用的選擇。

回到您提出的解決方案，我認爲它不會很可靠地擴展。如果某個特定內容非常受歡迎，那麼您的一箇中心將嚴重超載，而其他中心則處於閒置狀態。您可能希望查看更傳統的負載平衡技術，這將允許您通過簡單地添加更多服務器來擴展。

來源

2010-09-01 07:50:01

球員有一個時間表，例如[視頻1]，[圖像1]，[圖像2]，[視頻2]等時間表，當它到期時重新開始循環，一個通道可以從10-11 AM顯示，而另一個通道從10:30-上午11:30。這意味着廣播不是一種選擇。此外，它的一個要求是，每個玩家（屏幕+電腦/ labtop）都可以「脫機」。這也是一個要求，他們中的一些工作在http上，因此他們可以位於一個小商店櫥窗中。 – 2010-09-01 08:48:11

有時間表的頻道......聽起來*就像播放給我一樣。多個客戶是否會訂閱一個頻道，或者*頻道*你真的認爲*客戶*嗎？無論如何，如果它通過互聯網，這是一個有爭議的問題，因爲不幸的是，UDP多播不起作用。 – 2010-09-01 09:02:29

對不起，我的意思是_client_。也就是在顯示器上顯示內容的客戶端。（我在我原來的帖子中也稱它爲「玩家」，我爲我的壞描述道歉。 – 2010-09-01 09:33:34

不要「選擇」的設計模式之前您設計。 先設計，然後與圖案進行比較。

您的設計不需要始終堅持模式。但是，請確保您的設計不符合反模式。

來源

2010-09-01 07:16:29 pavanlimo

+1 - 我同意：在挑選圖案之前，你需要做一些思考;解決方案（pattenr）應該始終適合問題 - 而不是相反。 – 2010-09-01 19:53:20

選擇哪種設計模式

回答

相關問題