首先,我应该说,虽然我已经编程了一段时间,但这是我第一次为工作而这么做,而且我对PHP还比较陌生。
我被要求创建一个PHP应用程序,从表面上看,它非常简单--尽管它有一些复杂的业务逻辑。基本上,它向用户显示了许多层叠下拉选项,然后当表单提交时,它从根据业务逻辑布局的数据库中返回一组数据。
到目前为止,我拥有的是许多php文件,其中包含数据库调用和html片段,JS调用它们来显示每个下拉列表,然后再添加一个文件来创建生成的信息表,其中包含所有的业务逻辑和更多的数据库调用。
我相信您可以看出,目前代码主要是过程性的,但是由于它必须在大量web页面上发布,我一直在研究不同的体系结构,以便以更易于维护和更可伸缩的方式来布局代码--这是我过去一周一直在研究的,但我没有进一步深入研究。
我一直在研究MVC/MVP之类的东西,但是我还不太明白,因为很多信息是相互冲突的,据我所知,它并不严格适用于web应用程序,因为它最初是为桌面应用程序设计的。然而,我偶然发现了对我来说有意义的三层结构的一个很好的描述,即:
然而,我不知道如何在实际中做到这一点。到目前为止,我的想法是:
我的主要问题(除了这是个好办法吗?)是应该在浏览器(Ajax)调用的business_logic字段中实例化“business_logic”类以处理所有级联下拉列表和结果,还是应该为每个类维护一个单独的文件?
注:为了缩短这个问题,我遗漏了有关用户输入验证和数据库连接等类的信息。我还故意避免使用像Symfony、CodeIgniter或CakePHP这样的框架,因为它正在被放到一个已经存在的网站上,而且它是一个小应用程序。
您所能提供的任何建议或帮助都将不胜感激!
发布于 2017-09-15 17:56:58
三层结构似乎很好。但是,我会尽量避免创建包含整个应用层的类。
相反,将层划分为名称空间。
在表示命名空间中,您可以创建从http请求中提取数据的类,调用应用程序逻辑,然后将结果封装在http响应中(包括呈现的html / JSON /.)。每个数据结构或业务逻辑的一部分都需要一个类来完成任务。
业务逻辑命名空间可能包含在应用程序上下文中每个执行一项具体任务的类。根据我的经验,这在业务逻辑层是最重要的。
最后,数据访问命名空间将包含便于访问数据结构的类。这个名称空间中的每个类都可能映射到应用程序使用的数据结构,除了从DB (或其他API)获取数据并返回包含该数据的对象或对象数组之外,什么也不做。
最后,我明白为什么您不想使用臃肿的框架。不过,看看西列克斯 --它没有规定任何特殊的代码组织方式,除了依赖注入、路由和Symfony Request/Response类之外,几乎什么都没有,所有这些都非常方便(特别是对于可伸缩性)和实现自己的麻烦。
https://softwareengineering.stackexchange.com/questions/357465
复制相似问题