创建对象之前，如何处理许多必要的验证检查？ [英] How to handle a lot of validation checks necessary before creating a object?
问题描述
我有一个模拟FK关系的类。它有2个列表。这些列表包含父表&的列名称。子表分别。这些清单是客户传递给我的。现在，在创建我的FK对象之前，我认为有必要（按顺序）进行以下检查：
I have a class which models FK relationship. It has 2 lists in it. These lists contains the column names of the Parent Table & the Child Table respectively. These lists are passes by the client to me. Now before creating my FK object, I think it is necessary to do following checks (in order):
- 检查列表是否不为空。
- 检查列表是否包含空值。
- 如果列表包含重复的列？
- 两者的大小列表是相等的。
- Check if lists are not null.
- Check if lists contains null.
- If a list contains duplicates columns?
- Size of both the lists are equal.
因此您可以看到总共有7张支票。可以进行这么多检查吗？
So you can see there will be total 7 checks. Is it OK to have so many checks?
如果可以进行这么多检查，是否有任何模式可以处理这种情况（验证检查的数量很高）？
If it is OK to have these many checks, is there any pattern to handle such cases (with high no. of validation checks)?
如果还不行，那我该怎么办？我是否应该将这些条件记录为合同和合同的一部分？提到如果违反此合同，API会产生荒谬的结果吗？
If it is not OK, then what should I do? Should I just document these conditions as part of contract & mention that API will produce nonsensical results if this contract is violated?
编辑：基本上，我试图将这两个列表和产生特定于数据库的查询。因此，正确构建此对象非常重要。
Edit : Basically, I am trying to takes these 2 lists & produce a Database specific Query. So, it is kind of important to have this object built correctly.
推荐答案
就像每个人所说的，它取决于您。尚无此固定/标准指南。但是，为了简单起见，必须将所有验证逻辑放在一个地方，以便保持可读性和易更改性。
Like everybody says, it depends on you. There is no such fixed/standard guideline for this. But to make it simple, you must have to put all your validation logic in one place, so that it remains readable and easy to change.
建议如下：您说过，您所有的验证逻辑似乎都是面向业务的。.这意味着最终用户不应为您的数据库配置而烦恼。假设您的类名称为FKEntity。因此，如果您遵循实体概念，则可以将验证逻辑放入FKEntity.validate（）（实现接口Validatable）中，该逻辑将验证特定实体……这是适用于适用于所有FKEntity类型对象的那种验证逻辑以同样的方式。并且，如果您需要任何验证逻辑来相互比较/处理不同的FKEntity（例如，如果有一个FKEntity的值是 x，那么没有其他实体可以以 x作为它们的值），那么您可以不允许整个实体列表都保留下来），则可以将逻辑放入服务层。
A suggestion can be, as you said, all of your validation logic seems to be very business oriented..by which I mean the end user should not be bothered about your db configuration. Let assume your class name, FKEntity. So if you follow the entity concept then you can put the validation logic in FKEntity.validate() (implementing an interface Validatable) which will validate the particular entity...this is for those kind of validation logic which applies to all FKEntity type objects in same way. And if you need any validation logic that compares/process different FKEntity depending on each other (e.g. if there is one FKEntity with some value "x" then no other entity can have "x" as their values, if they do, then you can not allow the entire entity list to persist), then you can put the logic in your Service layer.
Inteface Validatable { void validate() throws InvalidEntityException; }
Class FKEntity implements Validatable {
//..
public void validate() throws InvalidEntityException {
//your entity specific logic
}
}
Class FKDigestService {
public digestEntities() {
try {
for(FKEntity e : entityList)
e.validate();
//your collective validation logic goes here
} catch (EntityValidationException e) {//do whatever you want}
}
}
这将为您带来两个好处，
This will give you two advantages,
-
您的特定于实体的验证逻辑放在一个位置（尝试将大多数逻辑视为特定于实体的逻辑）
Your entity specific validation logic is kept in a single place (try to think most of the logic as entity specific logic)
您的集体逻辑与实体逻辑分离，因为您不能将这些逻辑放入您的实体中，因为这些逻辑仅在有FKEntity集合时才适用，但不适用于单个实体...这是业务逻辑，而不是验证逻辑
Your collective logic is separated from entity logic, as you can not put these logic in your entity since these logic is only applicable when there is a collection of FKEntity, but not for single entity...it is business logic, not validation logic
这篇关于创建对象之前，如何处理许多必要的验证检查？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
