在Rails中构建核心商店框架。合适还是不合适？

Question

我在一家内部IT部门工作，为公司运行10家左右的商店，这些商店的复杂程度各不相同。商店代码已经写了过去8年，每个商店一个新的分支越来越父亲和父亲远离干（我猜这使它布什？）

需要更多和更复杂的折扣，活动和用户监控正在迅速增长 - 并且也在迅速变化（你永远不知道他们提出了什么）。所以我们决定从头开始编写一个新的系统，并将不同的商店放在一起，使它们在相同的核心代码上运行。我们已经考虑过.NET，但由于设计要求变化太快，我们或多或少地决定给Rails一个尝试。但是我们有一些关于轨道的不确定性/问题。

是铁轨（栈）适用于运行建立一个店框架以及谁应该这个组织？

我们正在运行约10店，其中一些非常相像只是在风格上，在别人脱颖而出的功能，流量和内容的不同。但业务逻辑背后都是一样的。商店的功能也很好。例如，一家商店的结账页面可能会显示关于增值税，折扣，P & P等的详细信息，因为另一个商店可能只显示必要的最低限额。

你会采取哪种方法？你会建立和维护一个可运行的模板商店，并带有商店的功能超集。 随着新功能的开发，将代码与其他商店合并？听起来有点麻烦。如您外部化的配置，如付款方式类型

与结账页面views会从不同店铺购物的例子，但controllers和models将保持不变，只要等。

从这个角度来看，它将更有意义为每个商店创建视图和配置的存储库，然后将模型和控制器代码保存在单独的存储库中。

将有可能根据车间安排的意见，保持所有资源在一个repositoary /views/shopname/Product。这有意义吗？

你觉得呢？你会如何做到这一点？以这种方式使用轨道会带来很多麻烦？

我们的活动/折扣系统的发展非常复杂，包括GUI和业务逻辑。 （在这个视图中Rails看起来很有趣，它的快速转变）。我们的折扣是基于财产的，这些属性存储在数据库行中。

将需求变更为折扣的工作是一件非常头疼的事情。所以我们正在慢慢地用一个系统替换这个基于财产的系统，每个折扣都附加一个类（PHP）和一个配置，以便每个折扣类型都有它自己的类，并且这种折扣的每个利用可以指定这个类操作的一些值给定当前的背景下（基本上是：什么在篮子里）

在rails中你会采取什么方法？

在rails中，你可以很容易地扩展你的模型（折扣）与另一个属性，迁移，你准备好了（也许有点简化）。你可以编写一个基础折扣类，它依赖于几个基本属性，然后编写钩入（扩展）这个类的模块，以防需要更高级的功能。

具体来说，这是Rails术语中的一个助手吗？

这篇文章的一些可能有点不清楚。请提问。另外我正在学习Rails，所以如果不使用正确的术语或者我错过了Rails的一些主要思想，请原谅我。

感谢 迈克尔

Answer 1

是铁轨（栈）适用于运行 建立一个商店框架，应该如何 这个组织？

当然，也可以是适合见：

• http://www.shopify.com/
• http://www.liquidmarkup.org/

我不会推荐它作为第一个项目，虽然。

Answer 2

不要忘记Spree Commerce作为一个可行的解决方案，可能或不会满足您的需求。另一方面，如果您想推出自己的解决方案，还请检查ActiveMerchant以进行支付网关集成。