我只能:
-
我应该使用PHP路由有在。Htaccess 这样写:
RewriteEngine on RewriteRule ^(.*)$ /index.php之后解析url像任何MVC框架?
注意:我喜欢这个想法，但我认为我自己写太多了，那么，我应该相信像klein和slim这样的小框架吗?
-
我应该在中写规则吗?Htaccess 为一些公共文件夹，只是阻止访问私有文件夹?
注意:当我们真正谈论文件访问控制时，我认为它更强大，更灵活。
我还想提一下，我没有使用MVC模式，我所说的一切都是基于我的知识贫乏，所以我想让你证明我错了，或者说我错了
对于我来说，我不希望我的应用程序过于依赖。htaccess规则。我使用一个简单的规则集，就像你在选项1中得到的那样，然后我让框架处理我的大部分路由。我每天都用Klein，而且很喜欢它。它功能强大且可靠，但是代码库相对较小，所以如果我真的需要的话，我可以深入了解它，看看发生了什么。我知道有些人也在使用并推荐Slim，尽管我自己用得并不多。在PHP中编写自己的路由代码非常简单，但是您将遇到许多边缘情况。
如果你严重依赖。htaccess，你可能会遇到一些问题。首先，.htaccess是递归解析的，因此Apache必须检查树下的每一个子目录中是否有.htaccess文件。链下的一些.htaccess规则实际上可能会覆盖您的逻辑，并产生意想不到的副作用。我认为Nginx或其他一些web服务器甚至不支持。htaccess，所以你将自己锁定在Apache中。一些主机提供商完全或部分阻止了。htaccess的使用。我个人认为，如果路由逻辑是用应用程序的语言编写的，而不是用。htaccess规则，那么路由逻辑将更容易理解，因此未来的开发人员也更容易维护。
最后，我要提醒大家不要放弃MVC模式。如果你的领域逻辑(模型)渗透到应用程序的其他部分，你或继承你代码的可怜的家伙将会陷入一个痛苦的世界。如果它是一个足够小的应用，将控制器和视图结合起来可能不会造成灾难性的后果，但大多数应用都会增长。即使您不遵循严格的MVC，也要遵循一些内部一致的模式，并将关注点分开。无论如何，我的投票倾向于一个具有最小.htaccess规则的微框架，因为它易于维护、易于开发、可移植性，甚至可能达到性能。如果过度使用，htaccess可能会导致性能问题(因为我提到的递归问题)。