architecture - 框架的特征是什么？

你的问题确实有点模糊，但在编码哲学方面它有点有趣＃34;我不会声称我的答案是做这些事情的唯一方法，特别是没有任何关于你的问题的具体细节。它只是我个人使用的一套指导方针，希望它们对您有所帮助。

因此，首先，您必须真正了解您要解决的问题。我不会考虑＆＃34;我是出于教育目的而做的＃34;作为一个选项在这里。试着问自己这样的问题：

你需要解决一个单一的问题吗？

一个简单的例子：如果您的应用程序需要对数组进行排序，或者更接近您的字段，则计算均值或偏差 - 所有这些都是奇异的问题。你真的不应该在你的应用程序中包含一套完整的已知排序算法，只是为了对数组进行排序，就像你不需要一个深度统计分析系统来计算平均值一样。我考虑开发特定于您问题的库。

目前的解决方案有什么问题？

这种通用概念作为框架通常在当前解决方案存在时诞生，但有一种方法可以更有效地与其进行交互。在某种抽象的掩盖下隐藏糟糕的代码或设计是一个非常糟糕的主意。如果当前的解决方案运行良好，但其实现似乎是一个问题，我开始重构现有代码，而不是从头开始重写或隐藏它。

这是一个反复出现的问题吗？

通用部件最有价值的特性之一是可重用性。构建通用但有用的东西总是要困难得多。更难意味着昂贵，所以你必须证明浪费时间来构建通用块。如果您没有或者不能在一个地方使用昂贵的街区，那么您可能不需要它们，而是更好地开发混凝土解决方案。

我标出这些问题的原因是我经常看到其开发人员称之为框架的代码，并且花费了大量的时间和精力，但他最终做了一些不是框架的事情，最重要的是，它应该＆＃39;首先是一个。

所以，我们得到了你问题的第一部分：

是否有参考设计和实施框架？框架的特征是什么？应该有什么功能？

这里适合给你一个框架专用的设计指南和功能列表，但我不认为这是一个好主意。原因如下：没有ISO或任何其他官方或广泛使用的软件框架开发标准。这是因为框架没有解决特定问题，它提供了这样做的方法 - 这是它最重要的功能。

关于框架的一个非常普遍的误解是它们必须绝对透明，并且应该能够满足任何需求。框架开发人员和用户必须明白框架是硬连线的。而这并不是因为你不能这样做。你可以，它被称为元编程。原因是框架意味着一种不变的内部行为，通常称为框架的核心＆＃34;。它可能对客户端有用，可以扩展此行为，但不能修改它。

重点是，框架必须决定客户端如何与环境交互。在更严格的条款中，当客户端在框架内运行时，控制流是一种逆转：框架评估客户端的代码并进行适当的调用，现在它是调用客户端的框架，而不是反过来，就像它一样是普通的图书馆。当然，可能会有一些例外，但我在这里谈的是一般性的想法。

然后你问：

必须涵盖哪些必要条件？

正如您可能已经想到的那样，没有严格的要求。但是我想提出的建议很少：

整个框架应该完全代表一个特定的域（字段），但它不应该超出它。这意味着，如果您的框架进行财务分析，它可能不应该进行天气预报并且也是闹钟
框架应该有某种domain-specific language。它在哪种形式下并不重要。它可以是客户端操作的特定于域的对象，命名约定和适当的间接（抽象）级别，或者如果您愿意，您可以一直使用自己的解释器编写一种编程语言。它只是客户与更接近（例如，财务术语和操作）的东西进行交互的想法，而不是一些抽象的处理程序，指针和函数
应该是显而易见的，但不要随便提及它：在处理一般事务时总是计划扩展和扩展。只要它不与最初计划的行为相矛盾，实施和添加新东西不应该太难（我不容易说），但要小心，不要介入元编程太深入了

问题的最后一部分是：

ORM是否与框架相关联？

嗯，是的，不是。如果您的框架依赖于并非特定于每个实例的数据存储，那么您应该对此进行某种抽象。在这种情况下，ORM可能是最好的方法，但我想指出的内容很少：

好的，那是你的问题，但是如果你决定开发一个合适的框架，我想补充一些提示：

不要忘记你开发的方法来解决，而不是解决方案本身
不要试图解决所有问题＆＃34;，这意味着不要忘记你正在解决的问题。无论如何，你无法解决所有问题
不要专心或被不必要的功能分心，尤其是早期
在您计划编码的字段中找一位专家，他可能会深入了解需要什么，哪些不是
我发现对这种工作采用feature-driven development流程非常方便，因为框架意味着大量的功能可以让你分散你的努力，导致某种失败，如果你的方法不牢固的话。特别是如果你打算独自完成它，那么看到迭代的工作结果就是一种激励