是否应该通过使用存储过程获取长度来使字段长度成为动态的

本文关键字：段长度 字段 动态 获取 是否 存储过程 | 更新日期: 2023-09-27 18:04:35

在web应用程序(c# + SQL Server)中，用户界面中字段的最大字段长度是否由从数据库中获取的字段确定?

这是一个好方法吗?如果不是，请说明缺点。

是否应该通过使用存储过程获取长度来使字段长度成为动态的

听起来有点矫枉过正，除非你有非常特殊的理由。

我认为，您可以通过从数据库中获取长度，然后在HTML元素上动态设置它来实现这一点。

缺点取决于使用和必要性:

  1. 对于具有大量数据和字段要显示的大容量应用程序，这将意味着从数据库读取许多数据并添加处理以呈现UI。
  2. 这意味着UI高度依赖于数据库，这听起来像是回归，因为当前的实践和技术正在推动UI与数据库/后端解耦
  3. 在存在许多验证方法的情况下，从UI到中间件，这是不必要的
  4. 你通常也不会设计一个UI元素与数据库的长度相同…如果数据库字段长度太长，弄乱了UI，会发生什么?使用这种硬耦合，您将失去UI的能力和控制。
  5. 链接到点4)，这将意味着需要更多的工作，使您的UI更具响应性和跨设备可见没有问题，因为您的数据库决定表单字段长度。
  6. 链接到第5点)，这意味着如果你要改变数据库中的字段长度，那么你的UI立即受到影响…或者有被影响的风险。更多的维护工作。如果字段长度增加以满足新的需求，在使用相同数据库的不同系统中，那么您将不得不修复依赖于这些长度的UI……或者为了迎合另一方而妥协……或者折衷和系统。

不能完全依赖UI、中间件或数据库来执行验证。

如果你能说明你的用例就好了。

有趣的链接:

  1. 如何为用户定义字段设计数据库
  2. 如何使用从数据库中获取的字段设计动态表单
  3. 你们在哪里执行验证?
  4. 数据输入验证-在哪里?多少钱?

一种常见的方法是让源代码同时定义数据库大小和UI验证。例如，在实体框架中，你可以对c#对象本身设置大小限制;

using System.ComponentModel.DataAnnotations;  
namespace MvcDA {
    [MetadataType(typeof(ProductMD))]
    public partial class Product {
        public class ProductMD {
            [StringLength(50),Required]
            public object Name { get; set; }
            [StringLength(15)]
            public object Color { get; set; }
            [Range(0, 9999)]
            public object Weight { get; set; }
          //  public object NoSuchProperty { get; set; }
        }
    }
}

这在数据库和用户界面中都是很容易实现的。

如果你手工处理所有的对象和查询，那么你已经选择放弃了许多免费功能——这没关系，这样做有很好的理由，但要注意，如果你采用更有管理的方法，这是一个解决问题的方法。

不应该调用存储过程来检索字段的最大长度的两个原因:

  1. 这将降低用户体验。如果用户输入的字符串大于最大长度，那么他/她不应该等待他/她超过长度的响应。它应该是即时的。

  2. 如果你想提高应用程序的性能，就不应该有任何不必要的数据库调用。

建议方法:

  • 你应该放一个JavaScript方法/一些其他的前端检查来验证最大长度。

  • 如果你的用户足够聪明，可以禁用JavaScript代码，那么你应该在c#代码中加上一个检查，然后再对捕获的值进行预期的操作。

我已经为我的web应用开发了一个框架，这是实现的功能之一。

为了实现这个功能，我做了以下工作(我将不包括我开发和使用的框架的任何额外功能):

  • 制作一个含有FieldName属性的接口IDbMappable, TableName (TableName)可以留空，然后使用含有Page的TableName。如果设置了FieldName，则TableName 必须在控制级别或页面级别上设置)
  • 制作自定义控件类(继承现有控件并实现IDbMappable接口)[TextBox控件可以用于任何东西(同时保存数据将被尝试转换为数据库中的数据类型)，CheckBox用于布尔字段，DropDownList用于外键字段等]
  • 加载页面时，如果页面上设置了TableName属性，则所有未设置TableName属性的控件将从数据库中获取各自的限制;对于在控件上设置了TableName属性的控件，每个控件将向数据库触发一个单独的查询以获取其限制。(限制就像最大长度，如果空白是允许的或不允许的，可能的一组值从下拉列表等)[我有一个基类为每个页面;我的页面不直接从System.Web.UI.Page类继承，而是从我的页面类继承从System.Web.UI.Page类]

我还为关键字添加了阅读描述，如:

  • [Email]用于任何应该只包含有效电子邮件id的字段(正则表达式是为这些字段自动生成的)
  • [Url]为有效的url(仅url)
  • [Uri]为有效的uri
  • [RegEx: expression]用于指定正则表达式。[注:方括号是通过它们的开始和结束来映射的，所以表达式可以包含方括号而没有任何问题]。

现在，这种方法的利弊

优点

    这种方法消除了许多琐碎的任务(如设置TextBox的MaxLength，在DropDownList中加载值，放置RequiredFieldValidator等)
  1. 这大大提高了我的生产力
  2. 代码看起来整洁干净(只有所需的逻辑在页面上;OK，还有更多)
  3. 我更自由地改变数据库的设计和布局。

缺点

  1. 如果我们把/填充对象/属性/控件，如MaxLength, RequiredFieldValidator等在设计时，然后这些值编译和运行得更快;在这种情况下，这些信息是从数据库中加载的，因此需要进行一次或多次数据库往返
  2. 新开发人员/其他团队成员大多会感到困惑的值是从哪里来的，或者为什么他们的字段值被覆盖(这可以通过实现像如果属性已经设置，那么不填充它;但是我覆盖了属性)
  3. 有点僵硬的架构，可能不适用于不同类型的应用程序(我在企业应用程序中使用这个框架;对于网站，我使用完全不同的方法来减少臃肿(HTML))
结论

根据要开发的应用程序的类型，这种体系结构可能是一种福音，也可能是一种诅咒。在高流量应用程序中，这无疑是一种诅咒，因为它将增加服务器级所需的处理需求和网络通信。但对于大多数企业应用程序来说，这绝对是一个福音。

我使用这个框架已经快5年了。这是第三次迭代改进，第四个版本正在计划中。

注意:在有人评论之前，我已经实现了获取信息的缓存(但在这里讨论有点复杂)

相关文章：