我在一家內部IT部門工作，爲公司運行10家左右的商店，這些商店的複雜程度各不相同。商店代碼已經寫了過去8年，每個商店一個新的分支越來越父親和父親遠離幹（我猜這使它布什？）在Rails中構建核心商店框架。合適還是不合適？
需要更多和更復雜的折扣，活動和用戶監控正在迅速增長 - 並且也在迅速變化（你永遠不知道他們提出了什麼）。所以我們決定從頭開始編寫一個新的系統，並將不同的商店放在一起，使它們在相同的核心代碼上運行。我們已經考慮過.NET，但由於設計要求變化太快，我們或多或少地決定給Rails一個嘗試。但是我們有一些關於軌道的不確定性/問題。
是鐵軌（棧）適用於運行建立一個店框架以及誰應該這個組織？
我們正在運行約10店，其中一些非常相像只是在風格上，在別人脫穎而出的功能，流量和內容的不同。但業務邏輯背後都是一樣的。商店的功能也很好。例如，一家商店的結賬頁面可能會顯示關於增值稅，折扣，P & P等的詳細信息，因爲另一個商店可能只顯示必要的最低限額。
你會採取哪種方法？你會建立和維護一個可運行的模板商店，並帶有商店的功能超集。 隨着新功能的開發，將代碼與其他商店合併？聽起來有點麻煩。如您外部化的配置，如付款方式類型
與結賬頁面views會從不同店鋪購物的例子，但controllers和models將保持不變，只要等。
從這個角度來看，它將更有意義爲每個商店創建視圖和配置的存儲庫，然後將模型和控制器代碼保存在單獨的存儲庫中。
將有可能根據車間安排的意見，保持所有資源在一個repositoary /views/shopname/Product。這有意義嗎？
你覺得呢？你會如何做到這一點？以這種方式使用軌道會帶來很多麻煩？
我們的活動/折扣系統的發展非常複雜，包括GUI和業務邏輯。 （在這個視圖中Rails看起來很有趣，它的快速轉變）。我們的折扣是基於財產的，這些屬性存儲在數據庫行中。
將需求變更爲折扣的工作是一件非常頭疼的事情。所以我們正在慢慢地用一個系統替換這個基於財產的系統，每個折扣都附加一個類（PHP）和一個配置，以便每個折扣類型都有它自己的類，並且這種折扣的每個利用可以指定這個類操作的一些值給定當前的背景下（基本上是：什麼在籃子裏）
在rails中你會採取什麼方法？
在rails中，你可以很容易地擴展你的模型（折扣）與另一個屬性，遷移，你準備好了（也許有點簡化）。你可以編寫一個基礎折扣類，它依賴於幾個基本屬性，然後編寫鉤入（擴展）這個類的模塊，以防需要更高級的功能。
具體來說，這是Rails術語中的一個助手嗎？
這篇文章的一些可能有點不清楚。請提問。另外我正在學習Rails，所以如果不使用正確的術語或者我錯過了Rails的一些主要思想，請原諒我。
感謝 邁克爾
每個問題請提出一個問題，這是太長以消化 – 2009-11-19 08:36:10
謝謝，我會記住的。 – Michael 2009-11-24 11:27:28