使用高阶函数实现类的扩展设计

发表于

在不少框架中,都会对“扩展”这一概念有需求。所谓扩展,即一个可组合的组件,用于嵌入到目标的生命周期中,对目标的行为进行额外的处理使得目标拥有不同的表现。 一个非常简单的案例即日志的记录。通常框架自身并不会有业务相关的日志记录的功能,而业务代码也不希望混入并非业务逻辑的日志记录部分。那么使用一个扩展,在合适的点进行日志的收集和存储是很合适的设计。 在以往,比较流行的扩展通常有几种形式: Mixin形式。这种形式下扩展与目标形成完全的覆盖关系,属于暴力而简单的方法。 class Component { constructor({mixins}) { mixins.forEach(mixin =>

聊一聊复用

发表于

复用是每一个工程师的追求,无论是设计还是编码我们最常说的除了“产品是SB”、“进度赶不上”外,恐怕就是“要好好复用”了吧。当一个应用或者一个系统日趋复杂的时候,我们总是希望其维护性不会线性地降低,而解决这一问题的方法上,就往往归结为简单的“复用”二字。 在与不少同学的沟通中,我发现有一部分工程师对“复用”的理解是有失偏颇的,在此针对比较容易出现的几类曲解进行一下解说。 复用的目的 我的论断很简单: 复用有很多的目的,但少写代码不应是其中一个。 注意这边说的是,少“写”

另类MVC模式 - 优势及实现

发表于

继续大逆不道系列…… 在上一篇中,提出了一个另类的MVC模型,与经典MVC模型有一些不同,那么自然需要描述这样的另类模型有什么优势,又能在怎么样的场景中使用。 逻辑划分 正如上一篇所说,这种模式下,最大的优势莫过于逻辑的清晰划分。在该模式的作用下,每一个Action都只要处理真正与自己有关的逻辑及数据,而不需要关心一些“通用”的内容,因为这些通用内容也成了独立的Action。 例如,继续引用上一篇中的页面设计,根据经典的MVC模式,我们不得不在一个Action中准备所有数据: public ActionResult ViewPost(int id) { ViewBag.

另类MVC模式 - 思考和雏形

发表于

这是一篇大逆不道的文章,其作用就是供大家娱乐以及批斗,因为此文所提及的思想,试图改变现有的著名模式MVC的结构,因此如果认为MVC优秀甚至完美的话,还请直接忽略此文,以免影响心情。 本文将提出一种类似MVC但又不完全是现有的经典MVC的模式,该模式仅基于HTTP的Web系统中对经典的MVC模式进行改造,其特点是将View前置,通过View的切分来切分逻辑,形成多次M-V-C交互,最终生成响应。 经典MVC模式 对于经典的MVC模式,虽然从表面上看完全是个“不需要解释”的问题,但是每个人的理解又不尽相同。在我的理解中,MVC模式可以用下面这张图来表达: 基于HTTP的Web系统里,在经典的MVC模式中,一个请求的处理过程大致分为: Controller处理原始请求,根据请求的数据与系统的配置,

单页系统前端MVC设计 – MVVM模式

发表于

在上一篇中,Action已经可以获取所有需要的数据,下一步就是将数据与视图中的控件树进行关联,使得View模块可以获取、修改数据,并通过与Action的进一步交互来完成整个业务逻辑。 MVVM模式 在介绍本文的ValueStack和ModelDescriptor这两个在整个框架中意义非凡的组件之前,需要先简单地介绍一下MVVM模式。 这个MVC框架引入了MVVM模式,MVVM模式的全称是Model-View-ViewModel模式。该模式顾名思义地有三个部分组成: Model:即数据,所有可持久化和不可持久化的,与业务有着关系的内容都可以被称为数据。Model的数据是扁平的,为了区别下面的ViewModel,这里可以称之为FlatModel。 例如,一个系统有用户,以及用户发表的文章,期间是1:n的关系,那么Model就存在两条数据。其一为user,