在 ASP.NET MVC 应用程序和 Java Web 应用程序中，有一种常见的做法是将业务逻辑保存在单独的包/dll 中，并将数据库和交付机制（Web 应用程序、Web 服务、本机移动或桌面等）视为插入的细节。
我可以说这种结构的一些优点是：
但这种做法在 Rails 社区中并不常见；我没有看到任何 Rails 应用程序将业务逻辑保存在 gems 中，并且主要的 ORM 都将持久性逻辑和业务逻辑联系在一起。Ruby 是否有一些东西使我提到的结构化应用程序变得不必要？
定义“必要”。在 .NET 或 Java 中没有必要这样做，它很方便。
Rails 应用程序通常只在单个应用程序中完全公开 Web 应用程序和相关服务。
测试类似；没有必要为了单独测试代码而分解应用程序功能，在 Rails 中的测试也不例外：有可以在任何级别的代码运行的单元测试、规范等，以及模拟任意部分的各种机制的功能。
持久层通常由 AR 层处理，尽管在实践中实际切换持久层是相当不寻常的（我在 30 年的开发中恰好这样做过一次，但这显然是轶事）。此外，由于鸭子类型，Ruby 中的一些此类切换在代码级别是透明的（例如，我通过移动到 ActiveResource 而不是 ActiveRecord 将一个应用程序从本地 DB 切换到服务几乎是透明的，尽管我没有尝试之后优化任何东西，数据模型非常简单。）
综上所述，IMO Rails 社区经常忽略“企业”商店的实践，因为 Ruby 语言使得构建功能变得非常容易，而无需过度架构。然而，只有在应用程序达到一定大小后，这种限制才会变得清晰。
Ruby 和 Rails 开发的最新趋势包括我多年来在企业中所做的事情（并且在 Ruby 中实现比在 Java 中容易得多）。但是，为了自己的缘故将功能分解到库中并不是特别有用。识别应该被分解的代码是，但是当有必要这样做时，它会跨环境发生。
Rails 是关于约定优于配置的。以及已提出的意见/最佳实践。
我认为将 BLL 分解为 Gem 并没有什么大的优势。除非我有独立于我的网络应用程序并且可以重用的代码。例如，我最近为一个公司论坛构建了一个 BBCode 解析器，所以我将它打包为一个 GEM，可以插入任何 Rails 应用程序。github 上有数以千计的 GEM，它们在功能上扩展了 rails。
为 Rails 应用程序制作 GEM 的整个想法应该是代码重用。如果您分离代码只是为了尝试遵循更多的代码分离，那么您就不会依赖 Rails 约定，并且如果任何其他 Rails 开发人员加入您的项目，他们将有一个学习曲线。
您可以使用任意数量的测试系统，它们不会在 Rails 中加载 Web 框架。在整个巨大的主题中进行测试，我会研究 RSpec 等等。并且有一些方法可以加快测试速度（例如使用 Guard 和 Spork）
这完全取决于应用程序。Rails 的想法是让您的应用程序快速完成。根据我的经验，Java 开发一直非常缓慢。ASP 也一样。但这些可能只是“糟糕的经历”。很多人都信誓旦旦。
大多数情况下，这只是关于努力和配置。让我们分解各个点：
努力：设置一个新的 gem 需要一点时间（每个项目都有自己特定的一组依赖项——测试、模拟、文档等）
配置：由于大多数 Rails 应用程序使用 ActiveRecord；拆分模型层有点困难（尽管很多 宝石都 这样做）。 不过，这有助于减轻这方面的痛苦。Rails::Engine
成本：对于大多数 Rails 项目，通过将代码拆分到单独的 gem/repo 中获得的收益很少：
大多数项目不会在彼此之间共享代码（当他们这样做时，他们会设置 gem）
有——或者应该有，通过正确的设置——你测试代码的方式没有区别；无论是在 gem 中还是在您的主项目中。（您可以在不使用控制器等的情况下测试模型 - 没问题）
主要的好处是在接口/层之间强制执行显式契约——这在 Ruby 社区中不太普遍