我有一个以这种方式工作的框架：在定义一些元数据之后，它使用PHP类生成PHP代码。这些类是抽象的，旨在进行子类化。
例如，如果我在后端定义一个User类，它将生成一个UserBase类，我只是将其子类化为：
class User extends UserBase {
//....
}
UserBase提供了一些常规功能，例如已定义的属性年龄，名称，电子邮件以及这些功能的getter和setter。它也验证。
接下来，它会生成一个UserDataMapper类，可以将用户保存到数据库，或者从数据库恢复用户，查找用户，删除用户等。
PHP代码分为3部分：
1）系统代码（“请勿触摸！”）
2）自动生成的代码（“不要手动更改！”）
3）用户代码（“做你想做的！”）
在分层思考时，系统代码对自动生成的代码了解不多（至少对于一些罕见的特殊情况），并且不了解用户代码。自动生成的代码使用系统代码，但对用户代码一无所知。用户代码使用系统代码和自动生成的代码。
我正在为我的框架编写文档，我在这里命名图层时遇到了问题，尤其是自动生成代码的图层;）
那我怎么称呼它呢？ “服务层”可能吗？因为实际上，自动生成的代码只是方便用户帮助他简化生活，并且只需按下后端的一些按钮即可快速进行重构。
对此有任何建议会很高兴。谢谢大家。
答案 0 :(得分：1)
应用程序Skeleton图层，还是只是Skeleton？
答案 1 :(得分：1)
嗯......这是一个棘手的问题，因为这个架构并不真正符合任何标准模型。
也就是说，只要您没有其他系统服务（例如邮件传输，日志记录等），“服务层”似乎合理适当。如果您有这些服务（我怀疑很可能），然后事情会变得混乱。
作为建议如何“抽象”或“切换”层？ （这实际上取决于该层提供的设施。）
答案 2 :(得分：1)
InterViews是一个非常好的用户界面系统，建于80年代后期。它有一个名为ibuild的用户界面构建器，这是我第一次看到系统生成的代码被设计为通过子类进行自定义。 http://portal.acm.org/citation.cfm?id=120804
他们使用的图层名称是：
核心类已生成且从未修改过。对于每个核心类，都有一个核心子类，它只是一个简单的C ++存根。如果核心子类在代码生成时不存在，则生成它，否则假定有人已经定制了它。因为核心子类非常简单，所以无论生成的代码或系统代码如何变化，它们都不会改变。
我不会过分担心你的图层名称。这是一个如何生成代码的漂亮模型，人们会很快意识到它是如何工作的。