0

我正在编写一份申请，详细说明申请人通过 Salesforce 在我们公司的状态；当我们的一名员工输入他们的查询 ID 时，它会显示他们的状态（已清除、未清除），如果未清除，则显示申请人在继续其计划之前需要解决的问题。

我想确保我正确地考虑了我的应用程序的不同区域。这是我所拥有的：

  • Model : 申请者类有一个动态函数，如Application.find_by_Enquiry_Token__c_and_Account_dot_LastName_from_Opportunity，请求时返回来自 Salesforce 的信息
  • 控制器：解析来自 Salesforce 的返回数据并使用信息创建哈希，例如@applicant[:general_information] = {:first_name = data[:Account].first[:FirstName], :last_name = data[:Account].first[:LastName]}.
  • 查看：显示控制器生成的信息。但是，它有自己的逻辑和检查，例如div根据它们是否清晰（class="success"）、是否不清晰（class="danger"）或是否有一些条件信息（class="warning"）来改变 a 的颜色。

我认为我有这个正确的，除了我有点担心我的观点，因为我有一些 Ruby 代码在那里根据返回的数据执行检查，主要是为了着色但也显示某些错误。这可以吗/这是否符合标准？还是我应该尝试重构我的应用程序并将其推送到控制器？

4

3 回答 3

0

模型是您的应用程序的业务逻辑所在，包括解析数据以及与您的域相关的所有内容。

控制器处理与用户的交互。因此，基本上，在 web 应用程序中，如果用户访问 URL，您的应用程序应该做什么。除了将任务交给其他类然后渲染视图之外，这不应该做任何事情。

意见就是这样。它们应该尽可能简单明了。您可以将视图中的逻辑提取到助手甚至演示者/装饰器中。视图处理向用户显示的内容。

在您的应用程序中，我将拥有：处理与 Salesforce 通信的 SalesforceApiGateway 类，如果已经有一个宝石可以处理这个问题，我不会感到惊讶。

您正在访问的每个 Salesforce 资源的模型类。这些将设置对 API 网关的正确调用，以提取给定资源的正确数据。这可能会很快变得棘手，并且可能需要进一步提取：1 个用于与网关接口的类和一个模型类，用于从应用程序访问它们的资源。

您的控制器不应解析任何 Salesforce 数据，而是接受用户请求并将其连接到正确的模型。

要记住的最重要的事情是你的课程应该只做一件事和一件事。如果你不能在不说“和”的情况下谈论你的课程，那么它可能做得太多了。所以你有一个与 API 接口的类。您有一个解析 API 的类。你有一个类可以将 api 的资源带入你的域等。

于 2013-09-21T11:34:38.577 回答
0

我会说，只要您不在视图中执行长查询或设置实例变量，像您在视图中那样使用一些 ruby​​ 代码就可以了。另一个开始将代码从视图移动到控制器的迹象是，如果您觉得视图变得杂乱且难以理解。从你说的看，这似乎不是问题。

我建议更改的一件事是使模型上的方法名称更短。更短的方法名称更容易理解，并且正如您所拥有的那样，方法名称非常长且笨拙。除此之外，我认为你做得很好！

于 2013-09-21T05:58:54.373 回答
0

在视图中显示正确的类很好，在其他任何地方都无法做到。如果您觉得您的视图变得杂乱无章，请考虑将它们分成部分或使用Haml代替 ERB 作为视图。

于 2013-09-21T07:12:32.127 回答