Question

我对设计模式的经验和理解来自与Laravel的合作，所以我实际上只是在MVC设计模式中经历过，但我发现自己正在开发一种自动编译＆＃34;查看每个CRUD操作，例如我通常在我的模型中放置一些Array来描述我希望如何为模型本身生成视图，然后我写出一个读出模型属性的一般视图并且基于数组，它将根据需要生成字段，如：

class User extends Model{
    public $editFormArray=array(["name","text",20],
                                ["surname","text",30]);
    [...]
}

并且视图将具有加载发送给它的模型的实现，并且基于$ editFormArray的特性，它将生成自己

类似的东西：

@foreach($resource->editFormArrayas $currForm)
    @if ($currForm[1]=="text")
        <div class="form-group">
           <div class="col-md-12">
              <input name="{{$currForm[0]}}" type="{{$currForm[1]}}"
                     placeholder="{{$currForm[0]}}" size="{{$currForm[2]}}">
           </div>
        </div>
    @endif
    [...]
@endforeach

这种方法让我只为CRUD操作创建了一个视图（还有一些视图无法根据需要自动计算），并且还允许我更改模型表单。飞行，添加，删除和编辑我认为适合的字段，但也使我的模型文件真正加载。

我的一位同事最近参加了一个关于设计模式的课程并且认为这是一个不好的实践，说一个普通的MVC，为每个单一模型CRUD操作手动生成的View将是正确的方法，但是我认为他错了，因为View本身并没有真正计算任何真实的逻辑（所有的逻辑实际上都保存在控制器上），它只计算＆＃34;显示逻辑＆＃34;正如在正确显示UX本身所需的逻辑中一样。

有人可以对这些争论有所了解吗？

Answer 1

混合设计模式并不坏。但是你必须考虑一些基本原则。

我需要编辑多少个文件才能修改此模板？我是否编辑了控制数据存储/检索和业务逻辑的相同文件？
看到模板的人是否知道“$ currForm [0]”的语义含义是什么？什么是下一个需要编辑这些东西的人才必须继续？

你基本上只是提出一个论点，即在模型中定义更多东西会使迭代更快。也许如果你的团队由一个人组成，并且他们可以将系统保持在他们的头脑中，可以是真的，但是当团队或项目扩展时它不正确。

https://stackoverflow.com/a/3477771/128581

“经常被遗忘的软件工程基本事实” 作者：Robert L. Glass，（IEEE Software May / June 2001中的一篇文章），He 谈论软件“60/60”规则，即典型的维护消耗40％到80％（平均60％）的软件成本，然后再消耗增强功能负责大约60％的软件维护成本，而纠错率约为17％。

如果有时高达80％的软件成本是维护，请尽量使其易于维护。如果使用得当，关注点分离可能会有所帮助。不要聆听直接的教条，但你必须仔细思考一些事情对于其他人有多容易理解，以及它如何帮助你避免常见的软件错误。

设计模式的混合是一个糟糕的实践吗？

1 个答案: