问题标签 [software-design]

我需要使用 jQuery 生成 HTML 片段。这些片段的创建取决于一些数据。数据存储在服务器端的会话中（使用 PHP）。

目前我实现了这一点
- 通过 AJAX 以 JSON 形式从服务器检索数据
- 并通过读取这些数据的特定 javascript 函数构建片段

问题是数据的复杂性越来越大，因此序列化为 JSON 变得更加困难，因为我无法自动完成。我无法自动执行此操作，因为某些信息是明智的，因此我生成了一个“剥离”版本发送给客户端。

我知道如果不阅读任何代码就很难理解，但我希望这是一个常见的场景，并且很高兴你能给我任何提示、建议甚至设计模式。

我是否应该在服务器上同时存储完整数据和剥离数据，然后使用一些库从剥离数据中自动生成 JSON？但这也意味着我必须让这两个数据同步。
或者也许我可以移动逻辑服务器端，这样可以避免发送数据。但这意味着发送 javascript 代码（因为我依赖 jQuery）。也许不是一个好主意。

如果不清楚，请随时问我更多细节。

感谢您的任何帮助

有人可以解释一下什么是软件框架吗？为什么我们需要一个框架？框架如何使编程更容易？

我见过每个类都有一个它实现的接口的代码。

有时它们没有共同的接口。

它们就在那里，它们被用来代替具体的物体。

它们不为两个类提供通用接口，并且特定于该类解决的问题的领域。

有什么理由这样做吗？

我正在考虑用 Java 或 C++ 等 OOP 语言实现一个具有有限状态自动机的程序。

对于良好的软件设计，您认为使用可管理数量的可用状态来实现这一点的最佳方法是什么？

为每个州实现一个自己的类是否很好？如果是，如何在两个国家之间架起桥梁？

感谢您的任何评论！

我试图找出用 Lua 注册我的 C++ 类构造函数的最佳方法（从软件设计的角度，而不是编码的角度）

我该怎么做？

我的想法：

1) 制作某种“初始化 Lua 绑定”文件，该文件绑定我希望在 Lua 中可用的每个 C++ 构造函数？（问题：这个文件会变得越来越大并且难以同步/调试）

2）每个类都有责任用我的“LuaManager”类注册它自己的构造函数（问题：为同一个A类一遍又一遍地将同一个构造函数绑定到Lua是愚蠢的，所以理想情况下，每种可编写脚本使用这种方法时，类应该只将它的构造函数与 Lua 绑定一次。）

非常欢迎想法或意见。

内聚和耦合有什么区别？

耦合和内聚如何导致好的或差的软件设计？

有哪些示例概述了两者之间的差异以及它们对整体代码质量的影响？

我的任务是构建一个流程来补偿我们的 LDAP 系统上的复制延迟。目前，有 1 个写服务器和 4 个读服务器。将条目写入写入服务器后，系统上最多可能有 4 秒的延迟，然后才会将条目复制到读取服务器。因此，如果我调用更新记录的服务“A”，然后立即点击应该读取该记录的服务“B”，则数据将是陈旧的。

为了解决这个问题，我计划构建一个缓存 Web 服务，以便没有应用程序直接与数据库交互，而是通过缓存服务。该服务会将所有创建、更新和删除存储在缓存中（大概是一个List<ModelObject>）。CRUD - R 条目需要在缓存中至少保留四秒钟。然后，当服务“B”尝试读取时，缓存服务将在对数据库执行读取操作之前检查缓存。

所以，我的问题是两部分。1）这是一个可行的解决方案，如果不是，你看到什么问题？2) 我将如何对 WCF 服务中的缓存进行维护。换句话说，有没有办法启动一个后台工作线程，从缓存中清除 4 秒前的条目？

假设我有 NavigationController->Root[Table View Controller 子类] 所以从didSelectRowAtIndexPath我的 Table View Controller 子类中，我必须将另一个视图控制器推送到 NavigationController。

访问 NavigationController 最优雅的方式是什么？我应该在我的表视图控制器中使用 NavigationController 的委托吗？如果我有多个从层次结构级别访问顶级对象的任务，这是最好的方法吗？

大多数情况下，托管对象上下文是在应用程序委托中创建的。将它传递给视图/控制器层次结构的方法是什么，因此树中的每个导航/选项卡控制器都可以访问它。每次从父母传给孩子可能不是最好的，因为我每次都必须携带这些信息，有时并不是所有的控制器都需要它。

StackOverflow 人群。我有一个非常开放的软件设计问题。

一段时间以来，我一直在寻找一个优雅的解决方案，我想知道这里是否有人对这个问题有一些出色的洞察力。认为这就像一个数据结构难题。

我要做的是创建一个能够从任何单位转换为任何单位的单位转换器。假设词法分析和解析已经完成。几个简单的例子：

为了让事情变得更复杂一点，它必须平滑地处理输入之间的歧义：

为了让事情变得更有趣，它必须处理复杂的单元而不需要列举所有的可能性：

没有正确或错误的答案，我正在寻找有关如何完成此任务的想法。总是有一个蛮力解决方案，但我想要一些简单且可扩展的优雅。