可替代松散耦合的mvc?

在代码因为高度解构主义而变得混乱和代码因为做x所需的一切都随机地分散在一个文件中而变得混乱之间总是有折衷的。

后者的问题在于,将事物分割成单个模块的“直观”方法在人与人之间是完全不同的。高度分解和分解的代码几乎总是更难理解,但一旦这样做了,维护就变得很容易了。我不同意这会让任何人困惑,除了作者看它。使用像mvc这样的大范围模式是因为随着时间的推移,发现它们并处理围绕它们构建的项目变得更加容易。

使用mvc的另一个优点是,如果不坚持分层的话,通常不会使应用程序更难维护。这是因为现在您已经有了一个预定的位置,可以放置实现新特性的任何方面。

考虑到紧耦合,如果没有层之间的连接,就不能真正实现一个特性。松散耦合并不意味着层之间完全互不了解,而是意味着层应该不知道其他层是如何实现的。例如:控制器层不关心你是使用SQL数据库还是只写二进制文件来保存数据访问层的数据,只是有一个数据访问层可以为它获取和存储模型对象。它也不关心您在视图层使用的是原始php还是smarty,只关心它应该以一些预先确定的名称提供一些对象。一直以来,视图层甚至不需要知道有一个控制器层——只需要调用它,并使用/something/提供的上述名称显示准备好的数据。

随着框架模板的发展,我发现mvc模式是构建应用程序最“松散耦合”的方式之一。

考虑应用程序各部分之间的关系,如接口或契约。该模型承诺将这些数据提供给视图和控制器。没人在乎 怎样 模特就是这么做的。它可以从一个典型的DBMS,如MySQL,从平面文件,从外部数据源,如ActuviSeruCE读取和写入,只要它完成它的交易结束。

控制器承诺向视图提供某些数据,并依赖于模型来实现其承诺。风景不重要 怎样 控制器会这样做。

该视图假定模型和控制器将遵守他们的承诺,然后可以在真空中开发。模型和控制器不关心视图是否正在生成xml、xhtml、json、yaml、纯文本等,它们在拖延合同的结束。

当然,视图和控制器需要同意某些事情的存在。没有相应控制器活动的视图可能工作正常,但永远不能使用。即使控制器没有 做 任何内容,就像静态页面中的情况一样:

<?php
class StaticController extends ApplicationController
{

    /**
     * Displays our "about" page.
     */
    public function about ()
    {
        $this->title = 'About Our Organization';
    }
}

然后关联的视图只能包含静态文本。(是的,我以前做过这样的事情。把一个静态视图交给其他人并说“就写在这个上面”是很好的。)

如果将m、v和c之间的关系看作契约或接口,mvc会突然变得非常“松散耦合”,要警惕独立php文件的诱惑。一旦你开始包含并要求六个.inc文件,或者将你的应用程序逻辑与你的显示(通常是html)混合,你可能已经把各个页面耦合得更松散,但是在这个过程中,把重要的方面搞得一团糟。

<?php
/**
 * Display a user's profile
 */
require_once 'db.php';

$id = $db->real_escape_string($_GET['id']);
$user_res = $db->query("SELECT name,age FROM users WHERE id = $id;");
$user = $user_res->fetch_assoc();

include 'header.php';
?>
<h1><?php echo $user['name']; ?>'s Profile</h1>

<p><?php echo $user['name']; ?> is <?php echo $user['age']; ?> years old!</p>
<?php
include 'footer.php';
?>

是的,“profile.php”和“index.php”完全不相关,但代价是什么?

编辑: 回应你的编辑:推动MVC。你说你有“一半程序员”,我不确定是哪一半(你有擅长html和css但不擅长服务器端的前端人员吗?有编程经验的作者?)但是使用MVC框架,你可以只把视图交给他们,并说“在这部分工作”。

我不得不说,我并不认为你的MVC有什么问题,因为你已经在使用模板了。我把它看作是当您试图向应用程序添加结构时自然演变的模式。

当人们第一次开始开发php应用程序时,代码通常是一团乱麻。表示逻辑与业务逻辑混合,业务逻辑与数据库逻辑混合。人们通常采取的下一步是开始使用某种模板方法。这是否涉及专门的模板语言(如Smarty)或只是将表示标记分离到一个单独的文件并不重要。

在这之后,我们大多数人发现使用专用函数或类作为数据库访问逻辑是一个好主意。这实际上不必比为每个常用执行的查询创建专门的函数并将所有这些函数放在一个通用include文件中更高级。

这一切对我来说似乎很自然,我不认为这是很有争议的。但是,现在您基本上已经在使用mvc方法了。除此之外的一切都只是或多或少的复杂尝试,以消除重写常用代码的需要。

我知道这可能不是你想听到的,但我认为你应该重新评估mvc。有无数的实现,如果真的没有一个满足您的需求,那么您可以编写自己的更基本的实现。

这样看:由于已经在使用模板语言,通常需要先创建一个普通的php文件,然后在每次创建新页面时创建一个模板文件。MVC不必比这更先进,在很多情况下也不需要。甚至你真正需要做的就是研究更复杂的处理数据访问的方法,并将其添加到你当前的系统中。

当你需要一个新页面时,你必须创建一个新的模型和控制器动作,我认为这并不意味着你的m,v和c层是紧密耦合的。这只是关注点的分离,有助于系统的解耦。

也就是说,完全有可能把mvc的意图搞砸(我已经开发过这样的应用程序),并使其组件紧密耦合。例如,站点可能会将“渲染引擎”直接放在控制器层中。这显然会增加更多的耦合。相反,一个好的mvc将被设计成控制器只知道要使用的视图的名称,然后将该名称传递给单独的呈现引擎。

mvc中糟糕设计的另一个例子是视图中有硬编码的url。这是路由引擎的工作。视图应该只知道需要调用的操作和操作需要的参数。然后路由引擎将提供正确的url。

zend框架是非常松散耦合的,非常好。过来看:

http://framework.zend.com

这篇文章也可能有用:

http://blog.fedecarg.com/2009/02/22/zend-framework-the-cost-of-flexibility-is-complexity/

你可以试试代码点火器。它非常容易学习,并且不严格采用mvc,同时为代码提供良好的结构。

代码点火器和kohana(一个ci的后代)是可以的,但也是松散的mvc。我喜欢 simple php framework . 它不会妨碍你,它提供了重要的东西,而不会强迫你使用一个结构或复杂的约定。

啊…很好的MVC论据。

我必须维护一个多方面的php应用程序,其中的一部分是以mvc风格编写的,但不是全部。更糟糕的是,不同的部分有不同的mvc实现方式,所有这些都是国产的。有些页面就是自己做的。

主要的问题不是框架代码的多样性,而是编码人员显然做到了 不 了解如何抽象api。 imo,这是mvc框架的最大问题。 我要处理的几乎所有代码都使用“models”作为放置函数的位置。这是一个 恶梦 维持。

要使这个可维护,IME需要一些东西:

• 一个独特且定义良好的数据访问层,其api边界负责检索和存储持久性存储,而其他的很少。

  我不喜欢用“模型”这个词,因为那是有争议的。不管该层调用什么,都不应该关心数据是如何存储的,甚至不应该担心数据库句柄之类的事情:即 全部的 数据访问层的工作。

• 一个非常轻巧的调度员,除了调度之外没有任何魔法。

现在你可以把所有其他东西放在一个接受请求和参数的地方,可能是从调度器归一化和错误检查,获取它需要的数据(通常是对象),做出需要做的更改,保存它需要的数据,手数据需要显示给视图。两百行代码在这项任务中费力地完成 作品 为了这一步。您不需要将位分割成从其他地方调用的另一个文件中的函数。你甚至可以把这个视图放在这个文件的末尾!理想主义是值得追求的,但实用主义需要关注,因为 这是可维护的 .

(好吧,大声嚷嚷……)

php缺乏对框架的强制,这意味着最好的框架做php做的事情:它们不会碍事。我研究过的一些最可维护的代码只有一个 require() 语句的顶部,对数据对象执行所有数据操作(看不到SQL),然后输出由模板函数包围的HTML,表单控件由一致的函数API执行。