我正在开发一个在登录时保存不可见用户数据的站点(例如,在另一个站点上的外部ID).我们将在创建帐户后立即创建/保存此数据.
我可以看到我们使用保存数据
我觉得#1可能是最合乎逻辑的地方,但是在模块中创建一个节点似乎并不是一件小事.
#3感觉就像解决这个问题的一种典型方法,但只是在一个繁琐的领域中拥有一堆序列化数据并不是最好的设计.
有什么建议？
国际海事组织,每个选项都有自己的专业和优势,你应该是最后一个人,你应该知道你的项目是什么,项目的关键点是什么,预期是什么典型的用户模式,可用的资源等等......
如果我完全自由选择,我个人最喜欢的选项是#4,#1和#5(等等!#5？是的:见下文!).我做出选择的指导原则是:
这将是一个干净的解决方案,你会为开发人员能够更方便地维护你的代码,因为所有的改动,用户将通过同样的渠道,它会更容易追查问题或增加新的功能.
我发现它并不特别简单,因为它要求您与该模块的自定义API进行交互.
至于可扩展性,取决于内容配置文件模块API的设计程度.诱惑可能是为了您的目的简单地使用所述模块完成的表,绕过API,但这使您有可能在某一天的关键安全更新中,您匆忙整个系统将崩溃,因为架构已经改变......
这将是一个干净的解决方案,因为您可以设计您的表(并且您的模块可以完全按照您的需要执行),并且您可以创建自己的API以供其他模块使用.另一方面,您将引入另一段代码来改变注册过程,这可能使开发人员更难以跟踪问题并以一致的方式扩展系统.
这在代码方面实现起来非常简单.此外,数据库设计也会受益:另外需要考虑的是表格很容易检查和查询.在大多数情况下,为视图创建新的处理程序非常容易:5个中的4个只使用随视图一起提供的原型对象之一.
当然,这将非常容易扩展.一旦你创建的模块为一个字段,你可以管理你想多为一个字段复制/粘贴代码到另一个(或如果你去OOP从同一祖先继承)为多.
我知道你已经了解了drupal,但是如果你需要一个如何做到这一点的指针,我在另一个答案中给出了一些指示.
那将是#4减去散布各种模块功能的缺点......当然如果你已经管理了200个字段,那么这不是一个可行的选择,但是如果你很早就进入你的设计,你可以考虑这个.
根据我的经验,几乎每个需要系统集成的项目(意思是:为多个系统中的同一用户同步数据)都有自定义的用户注册需求,我发现这个解决方案最适合我的需求有两个原因:
HTH!