Web 开发中的“约定优于配置”范式有什么好处?有没有坚持下去没有意义的情况?
谢谢
公约规定,90% 的时间它将是某种方式。当您偏离该约定时,您可以进行更改……而不是强迫每个用户理解每个配置参数。这个想法是,如果您需要它有所不同,您将在那个时间点进行搜索,而不是在通常没有真正价值的情况下试图围绕所有配置参数进行思考。
恕我直言,它总是有意义的。使约定优先于显式配置是理想的。同样,如果有人有顾虑,他们会强迫自己调查需求。
我认为好处很简单:无需配置。您不需要为这种或那种类型的资源定义位置,例如,让应用程序/框架自己找到它们。
至于没有意义的情况:任何需要替代配置的情况相当频繁,或者开发人员/管理员需要明确“选择”某些行为是有意义的(例如,以防止可能产生安全隐患的意外和意外副作用)。
Web 开发中约定优于配置范式的好处在于生产力,因为您不需要配置来设置所有规则,并且程序员必须做出的决定更少。这在使用 .NET Framework 时很明显。
最明显的好处是您将不得不编写更少的代码。让我们以 Java Persistence API 为例。当您定义一个具有属性和相应的 setter/getter 的 POJO 时,它就是一个简单的类。但是当你用 @javax.persistence.Entity 注释它的那一刻,它就变成了一个实体对象(表),可以在数据库中持久化。现在这只是通过一个简单的注释来实现的,没有其他配置文件。
另一个优点是,您的所有逻辑都在一个地方并使用一种语言(即您摆脱了单独的 xml)。
我认为这篇维基百科文章已经很好地解释了它:
约定优于配置(也称为约定编码)是软件框架使用的一种软件设计范式,它试图减少使用框架的开发人员需要做出的决策数量,而不必失去灵活性。这个概念是由 David Heinemeier Hansson 引入的,用于描述 Ruby on Rails Web 框架的理念,但与早期的想法有关,例如“合理的默认值”概念和用户界面设计中的最小惊讶原则。
这句话本质上意味着开发人员只需要指定应用程序的非常规方面。例如,如果模型中有一个类Sales,则数据库中对应的表默认称为“sales”。仅当偏离此约定时,例如“产品销售”表,才需要编写有关这些名称的代码。
当工具实现的约定与期望的行为匹配时,它会按预期运行,而无需编写配置文件。只有当期望的行为偏离实现的约定时才需要显式配置。