标签: architecture

我所知道的这样的问题这样,人们往往会讨论束的大致的Symfony 2的概念.

问题是,在特定的应用程序中,例如,类似于Twitter的应用程序,如果一切都真的在一个通用的包中,就像官方文档说的那样？

我之所以这么说是因为当我们开发应用程序时,一般来说,我们不希望将代码高度耦合到一些全栈胶水框架.

如果我开发一个基于Symfony 2的应用程序,并且在某些时候,我认为Symfony 2并不是保持开发进度的最佳选择,那对我来说是个问题吗？

所以一般的问题是:为什么一切都是一个好东西？

编辑#1

自从我提出这个问题以来差不多一年了,我写了一篇文章来分享我对这个主题的了解.

我经常看到人们说某些软件"非常自以为是",或者微软倾向于编写"无意见"的框架.这究竟意味着什么？

我读过SPA及其优点.我发现他们中的大多数都不能令人信服.有三个优点引起了我的怀疑.

问题: 你能否作为SPA的拥护者并证明我对前三个陈述有误？

                              === ADVANTAGES ===

1. SPA非常适合响应迅速的网站:

服务器端呈现很难为所有中间状态实现 - 小视图状态不能很好地映射到URL.

单页应用程序的区别在于它们能够重绘UI的任何部分而无需服务器往返来检索HTML.这是通过具有处理数据的模型层和从模型读取的视图层将数据与数据表示分离来实现的.

为非SPA持有模型层有什么问题？SPA是客户端唯一与MVC兼容的架构吗？

2.使用SPA,我们不需要对服务器使用额外的查询来下载页面.

哈,用户在访问您的网站时可以下载多少页？二三？相反,出现了另一个安全问题,您需要将登录页面,管理页面等分成单独的页面.反过来,它与SPA架构发生冲突.

3.可能还有其他优势吗？不要听到任何其他..

                            === DISADVANTAGES ===

1. 客户端必须启用javascript.
2. 只有一个网站入口点.
3. 安全.

PS我曾参与SPA和非SPA项目.我问这些问题因为我需要加深理解.没有理由伤害SPA支持者.不要让我再读一些关于SPA的信息.我只是想听听你对此的考虑.

我读到Linux是一个单片内核.单片内核是否意味着将完整的内核代码编译并链接到可执行文件中？

如果Linux能够支持模块,为什么不将所有子系统分解为模块并在必要时加载它们？在这种情况下,内核最初不必加载所有模块,并且可以维护模块中函数的索引并在必要时加载它们.

我正在用混合C和C++制作一个小项目.我正在我的一个工作线程的核心构建一个小型状态机.

我想知道你是否会在SO上分享你的状态机设计技巧.

注意:我主要是经过久经考验的实施技术.

更新:基于SO上收集的所有重要输入,我已经确定了这个架构:

我最近看到很多开发人员的职位发布,其中包括一个或多或少类似的句子:"必须具有N层体系结构的经验",或"必须能够开发N层应用程序".

这让我想问一下,什么是N-Tier架构？如何获得它的经验？

什么是数据传输对象？

在MVC中是模型类DTO,如果没有,有什么不同,我们是否需要两者？

我有一个用Python编写的应用程序,由相当技术的读者(科学家)使用.

我正在寻找一种让用户可以扩展应用程序的好方法,即脚本/插件架构.

我正在寻找非常轻量级的东西.大多数脚本或插件不会由第三方开发和分发并安装,但会在几分钟内被用户掀起,以自动执行重复任务,添加对文件格式的支持,所以插件应该具有绝对最小的样板代码,并且除了复制到文件夹之外不需要"安装"(因此像setuptools入口点或者Zope插件架构似乎太多了.)

是否有任何这样的系统,或任何实施类似计划的项目,我应该考虑一下想法/灵感？

好的,我有一个网站,您可以自己注册并登录.您还可以使用您的Facebook,Twitter或linkedin帐户登录.

用户只注册一个帐户很重要.所以不知何故,我想合并用户的帐户,如果他们使用不同的方法登录.解决这个问题的最佳解决方案是什么？

例如,用户使用他的Facebook帐户登录.我使用这些数据自动为他注册一个帐户.我应该发送一封包含我们网站用户名和密码的电子邮件吗？(如果Facebook的政策没有问题).我应该给他们第二个屏幕,他们可以填写用户名和密码吗？但这并不是使用您的Facebook帐户登录的理念.它应该简化您的参与程序.

用户也可以在我们的网站上注册,并在下次使用他的Twitter帐户登录时.如何将这两个帐户合并为一个？什么是最好的方式？

基本上我的问题是:我有4种不同的方式,用户成为我们网站的成员.如果用户决定使用多种方式,我如何确保所有这4种方式只创建一个帐户？什么是最好的流程,以确保它不会成为用户自己的麻烦？

编辑:

在我提出这个问题3年后,我在一系列文章中给出了答案:http://www.sitepoint.com/series/using-social-networks-as-a-login-system/

假设我们有一个用户,Wallet REST微服务和一个将各种东西粘合在一起的API网关.当Bob在我们的网站上注册时,我们的API网关需要通过用户微服务和钱包通过钱包微服务创建用户.

现在这里有一些可能出错的场景:

• 用户Bob创建失败:没关系,我们只是向Bob返回错误消息.我们正在使用SQL事务,因此没有人在系统中看到过Bob.一切都很好:)

• 用户Bob已创建,但在创建我们的Wallet之前,我们的API网关很难崩溃.我们现在有一个没有钱包的用户(数据不一致).

• 用户Bob已创建,在我们创建电子钱包时,HTTP连接将断开.钱包创建可能已经成功,也可能没有.

有哪些解决方案可以防止这种数据不一致发生？是否存在允许事务跨越多个REST请求的模式？我已经阅读了关于两阶段提交的维基百科页面,它似乎触及了这个问题,但我不确定如何在实践中应用它.这个原子分布式事务:一个RESTful设计文章似乎也很有趣,虽然我还没有读过它.

或者,我知道REST可能不适合这个用例.也许正确的方法来处理这种情况完全放弃REST并使用不同的通信协议,如消息队列系统？或者我应该在我的应用程序代码中强制执行一致性(例如,通过让后台作业检测到不一致并修复它们,或者在我的用户模型上使用"创建","创建"值等具有"状态"属性)？