问web应用程序中的自定义模板

EN

我认为，你选择自上而下还是自下而上来解决这个问题，在很大程度上取决于你所寻求的设计原则。

我从您建议的设计中得到的最大关注是应用程序层(例如。表示/GUI、中间层、数据库等)都很泥泞。单一层次的应用程序设计方法本质上没有什么问题，但是如果提供了一个体系结构需求或假设，即这必须是一个分布式多层应用程序，那么您的设计就已经违背了这些原则。

如果您将数据库过程标识为面向组件的体系结构中的独立组件，那么您现在也引入了紧密耦合。但是，如果您的组件都是在设计时考虑到垂直集成，那么这将不是紧密耦合。这是您需要检查的另一个体系结构假设。

除此之外，我在此之前确实参与过类似的设计方案，并亲自见证了这种设计方法的利弊。在我看来，康斯一家比这里的牧师还重要。这里的优点是，对屏幕上的布局和组件的更改变成了模式更改。如果您预期强大的用户将有能力深入定制他们的屏幕，那么这是一个理想的模型，但是如果不是这样，那么它就会受到限制，特别是当新的需求决定了特定的UI特性时。

查看基于组件的web框架(如ASP.NET或JSF )，看看这些框架是否能更好地满足您的需求，而不会违反MVC或其他体系结构原则。

编辑：

您的需求似乎确实规定用户将有能力创建自己的屏幕和表单。在这种情况下，自下而上的方法是最好的。

这仍然可以与多层体系结构和MVC模型一起工作，但它将是复杂的。在您的设计过程中，要记住以下几点：

解耦

将屏幕构建器模块与其他域、业务逻辑和数据访问分离。保持这些解耦使应用程序在添加特性时具有更高的可维护性和可伸缩性。

模型

本例中的模型将是您的应用程序业务逻辑、数据访问以及您希望声明的任何域模型实体。屏幕构建器模型与此分离。

视图(屏幕生成器、MVC和其他视图)

视图将包括硬编码的视图页以及整个屏幕生成器模块。

这是什么意思？

基本上，您的视图包含了用于用户动态屏幕的完全独立的自包含MVC设计。

• 屏幕生成器模型:对返回屏幕元素上数据的存储过程的数据访问。这也是返回数据的域模型。
• 屏幕生成器视图:生成动态用户生成视图的代码。
• ：存储过程和其他与控制器相关的任务，这些任务在获取和转换模型以及为用户构建视图之间起到了缓解作用。

控制器

本例中的控制器将是您的web应用程序框架控制器。

下面的模型为您提供了一种解耦的多层方法，方法是将动态表单生成的设计作为一个独立的MVC组件，在基于web的MVC设计中对您的整个应用程序进行操作。