database - 在构建高度定制的 Web 应用程序的同时克服内部平台效应的方法？

Question

请随意回答标题中的问题，就像我提出的那样，我在下面提供了一些更多的细节和细节。

目前，我开发和维护了一个有点遗留的业务应用程序 (ASP/SQL)，它是高度可定制的，允许适度到完全定制:自定义字段、表单、 View 、报告、操作、事件、工作流等。这种定制是在我们开发的领域中必不可少，并使我们能够建立一个利基市场。

我一直在阅读有关内部平台效应和实现高级用户定义自定义的方法的文章，并得出结论，我们确实遇到了许多内部平台效应问题，因为本质上我们已经在顶部创建了一个高级抽象的 SQL。自定义字段的组织以与此处找到的方法类似的方式实现

http://blog.springsource.com/arjen/archives/2008/01/24/storing-custom-fields-in-the-database/

我们使用类似于那篇文章中描述的元数据库方法。所有定制都是围绕这种方法构建的，并且在很多方面我们都在数据库之上遭受数据库的困扰。

最终结果在纸面上看起来很棒，但添加的功能越多，为客户完成自定义编码，一切就变得越乱。似乎我读得越多，我就越意识到这是一种反模式。似乎我尝试阅读的次数越多，我发现关于该主题的文章就越少。无论如何，我正在尝试学习解决这个问题的现代方法，并试图找到更多关于该主题的讨论/文章。 CouchDB 等数据库系统与此类应用程序相关吗？

我的问题显然很笼统。似乎有很多人反对这种应用程序，而只支持“更好地了解和定义您的域”。有什么好的/更好的方法来实现这种应用程序吗？我不是在寻找非黑即白的答案，任何关于这个主题的进一步阅读都会很棒。感谢您的帮助。

Answer 1

我的回答是有意识地清楚插件要做什么以及用户设置是什么。在这种情况下，您的平台和设置是不同的。您的应用程序提供基本服务，并且毫不掩饰地是一个平台。它还可能提供基于该平台构建的应用程序。

因此，在那种情况下，您关注的是程序员接口(interface)而不是实现可能性。