我应该使用什么类名来将类用于在nodejs中使用某种数据类型的CRUD

时间:2016-01-26 14:46:51

标签: node.js oop orm architecture

在很多情况下,我需要为某些课程编写很多关于CRUD的课堂作业。例如CRUD与纯对象User,Book,Tag。

我通常创建一个名为models的目录,将所有CRUD归入模型文件夹。

但我觉得model这个词并不显示本质。在计算机科学中明确定义model这个词吗?它意味着用户的纯粹对象,还是用户的CRUD手段?

我还使用另一个名称services来表示更复杂的逻辑,例如UserService可能需要其他models而不是UserModel。但是service这个词经常与其他一些案例冲突,比如在线服务,后端服务。

我的模型和服务有什么好名字吗?顺便说一句,我最常用的是Node.js;它可能与Node.js中使用的一般约定不冲突。

2 个答案:

答案 0 :(得分:0)

最终,它将归结为使代码对您和未来可能有机会处理代码的人最容易理解的原因。如果' model'和'服务'以明显的方式向任何进入代码的人传达对内在的想法,然后他们可能很好。至于标准,我不知道是否有定义的标准。你必须使用的一组名字。例如,在MVC中,您将使用' Models'作为您的一个文件夹,为了存储您将提供视图的所有实际模型,这在MVC架构中被理解为那些名称(模型,视图,控制器)是标准。

答案 1 :(得分:0)

我同意你的观点,Model有点含糊不清。有时它用于指示域对象,例如User / Book / Tag,但有时它用于指示处理业务逻辑的对象,例如“购买书籍”,“验证用户”。 这两种用法的共同点是“模型”与UI明显分开,完全由视图和控制器处理。

另一个有用的名称是实体。在Robert Martin关于面向对象设计的工作中,他谈到了用例驱动的设计,并区分了三种对象:实体对象,交互器对象和边界对象。

Entity objects在多个用例中很有用。例如,在图书销售系统中,实体可以是Book / User / Recommendation / Review

Interactor objects实现用例,它们通常使用多个实体对象。例如,Purchase_Book / Login / Search_Books可以是此类对象。

Boundary objects用于跨模块边界传输数据,用于构建系统各部分之间的接口,这些接口应该彼此分离。例如,控制器可能需要创建一个Purchase_Book对象,并且为了创建它,它需要传递有关需要购买的书籍ID的数据,通过什么用户ID等...以及此数据可以打包在名为Purchase_Request的边界对象中。

虽然InteractorBoundary需要更多解释,但我发现实体这个词很有意义,可以直观地掌握而无需阅读任何解释。