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

我的经验和对设计模式的理解来自Laravel的工作，所以实际上我只有MVC设计模式的经验，但是我发现自己为每个CRUD操作开发了一种“autocompiling”视图，例如我通常在模型中放置某种数组来描述我希望如何为模型本身生成视图，之后我编写了一个读出模型属性的基本视图，并基于数组生成字段需要，是这样的：设计模式的混合是一个糟糕的实践吗？

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

这种做法让我创建只有1 CRUD操作视图（和一些其他浏览不能自动计算，按所需的），也可以让我改变模型在飞行中形成，添加，删除和编辑字段，因为我在飞行中看到适合，但也使我的模型文件真正加载。

我的一位同事最近参加了一个关于设计模式的课程，认为这是不好的实践，说一个正常的MVC，每个单一模型的手动生成一个视图CRUD操作将是正确的方式来做到这一点，但我认为他错了，因为View本身并没有真正计算任何真正的逻辑（所有的逻辑实际上都保存在控制器上），它只计算“显示逻辑”，就像正确显示UX本身所需的逻辑一样。

有人可以对这些论点提出一些看法吗？

来源

2017-08-29 Yuri Scarbaci

它是一种不错的混合设计模式的做法。但是你必须考虑一些基本原则。

我要编辑多少个文件才能修改此模板？我是否编辑控制数据存储/检索和业务逻辑的相同文件？
有人只是看着模板有什么想法“$ currForm [0]”的语义是什么时，他们看着它？接下来要编辑这些东西的人会不得不继续下去？

你基本上只是提出一个论点，即在你的模型中定义更多的东西使迭代更快。也许如果你的团队由一个人组成，他们可以保持系统的头脑，可能是真实的，但它不是作为一个团队或项目的规模扩大。

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

在 “关于软件工程中经常被遗忘的基本事实” 由Robert L.玻璃，（在IEEE软件2001年5月/ 6月的一篇文章），有关软件他会谈 “60/60”规则，即维护通常会消耗40％到80％（平均60％）的软件成本，然后增加大约60％的软件维护成本，而纠错约为17％。

如果软件成本有时高达80％是维护成本，请尽量让维护变得容易。分离关注点，如果使用得当，可以提供帮助。不要听直接的教条，但你必须仔细考虑一下，为他人理解某件事是多么容易，以及它如何帮助你避免常见的软件错误。

来源

2017-08-29 19:45:52 Josh

基本上有良好的开发过程的文档，在这里和那里都有解释性的注释，同时以更容易理解的方式更改“自动设计逻辑”变量名称实际上是一个很好的方法，对吗？我的意思是我这样做，因为软件设计是不断变化的，所以不用编写，删除和编辑相同的东西，数百次这个接近我只需修改一个数组，添加/编辑/删除单个元素来获得结果显示在表示层，所以我的意图是加速维护。 –

是的，你错过了这一点，但是，嘿，如果你的老板让你这样做，那就去吧。 – Josh

好吧，事情是我在这种情况下是老板，而且我正在努力改进我在这件事上的决策，所以如果你能帮助我达到这一点，我想要了解它，我会喜欢它。 –

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

回答

相关问题