Clojure中的MVC模型

Ale*_*xey 6 model-view-controller orm clojure

作为Ruby on Rails开发人员,在设计/实现Web应用程序时,我从问题域中获取基本概念/实体并将其作为模型实现.通常,这些是从基本ORM类派生的类(例如ActiveRecord::Base),它们映射来自数据库表的记录,并添加包含实现与模型相关的业务逻辑的额外方法.

这种方法的优点是您可以快速找到与问题域中的对象相关的所有业务逻辑,这样,如果模型类不大,您就可以有效地理解应用程序的这一部分如何工作.它还与所有表示逻辑分开.此外,由于ORM,业务逻辑方法包含很少的特定于DB的代码,因此非常干净且易于阅读.

缺点是这类课程通常会变得庞大,因而整体难以理解.

所以我的问题是:

  • Clojure生态系统是否提供了一些与OOP的ORM具有类似功能的库?
  • 组织此类代码的"Clojure方法"是什么?
  • 该方法有哪些优缺点?
  • 一些文章/书籍/讲座解释并证明了这种方法的合理性?
  • 是否有一些开源(示例)应用程序展示了这种方法?

Art*_*ldt 8

Clojure开发背后的驱动理念之一是将复杂事物分离到最合理的程度,并将数据视为数据,从而避免将数据与单独的值状态和身份相结合.

  • Clojure生态系统是否提供了一些与OOP的ORM具有类似功能的库?使用将一个数据结构转换为另一个数据结构的纯函数来处理数据的愿望导致一些clojure程序员回避ORM,尽管如果你真的想要在Clojure中没有理由不能使用Hibernate.

  • 组织此类代码的"Clojure方法"是什么?我喜欢Amit Rathore对这个主题的介绍

  • 该方法有哪些优缺点?Rich Hickey在这个经典视频中对这些想法进行了很好的讨论
  • 一些文章/书籍/讲座解释并证明了这种方法的合理性?我个人推荐Clojure喜悦,


til*_*lda 8

简单地说,你不要将东西包装在一个对象中,你可以使用列表,集合和映射等数据结构直接编程.因此,完成ORM的工作减少了将一个数据结构转换为另一个数据结构:例如,user-row->user-record函数可能会将您从SQL数据库弹出的值列表转换为代表应用程序业务逻辑中的用户的映射.保存用户时,必须调用反向功能.

我不得不说,对于一个经验丰富的OOP程序员来说,实际上很难"得到"这样一个事实,那就是关于东西的仪式要少得多.我们的大脑似乎与这个想法作斗争 - 恕我直言,因为对于有经验的开发人员/软件架构师来说,这似乎太简单和不成熟.:-)我希望我可以写出更复杂的响应,充满了奇怪的术语听起来像一个真正的专家,但我实际上不能,因为没有更多的补充.:-)

顺便说一句,一个小但有趣的观点 - 数据结构的普遍使用是一种在OOP世界中被认为是错误的实践.例如,你不应该把钱存在一个简单的元组中[10, "USD"],而应该写完全public class Money包含所有货币,比较,舍入等.但是编写元组正是我们在FP中所做的.我记得我从OOP世界中得到了一些奇怪的感觉.

在组织代码时,或多或少与OOP中相同的规则适用于名称空间.您可以像在java包中一样组织基于主题的代码,除了所有函数(用于调用方法)现在都是无状态的,并且通常将上面提到的用户记录作为参数.因此,在纯函数返回新数据结构而不是修改状态的情况下,foo.barChange()您将拥有(bar foo)它.barfoo2foo

据说OOP的一个好处是,不仅有很多应用程序使用这种范例编写,更重要的是已经尝试了多方法(这就是我们如何得到像今天流行的DI容器等的东西...).功能编程还没有这个.基本上没有人有关于如何在FP中进行应用程序架构的经过验证的最终手册.顺便说一句,这就是为什么人们通常不鼓励编写大框架并鼓励他们继续使用数据转换功能.这样你就可以按照你想要的方式连接它,避免建筑陷阱.