The one thing that can still get me is what to return from methods? I know that you should be as specific as possible(ie don't return object if you need to return an int)
仍然可以得到的一件事是从方法中返回什么?我知道你应该尽可能具体(即如果你需要返回一个int,不要返回对象)
However it's cases like this
不过就是这样的情况
I have a service layer that contains business logic. Say I have a method called CreateAnEvent()
我有一个包含业务逻辑的服务层。假设我有一个名为CreateAnEvent()的方法
Basically it saves an event to the database and if successful it will return a string with "saved to database"
基本上它将事件保存到数据库,如果成功,它将返回一个“保存到数据库”的字符串
Now what happens if I first need to check if this event meets some business rules.
现在,如果我首先需要检查此事件是否符合某些业务规则,会发生什么。
- Can't be less than today's date.
- Can't be greater than one week from today.
- Can't be created on a Friday.
不能低于今天的日期。
从今天开始不能超过一周。
不能在星期五创建。
Something like that where I need to first do some business checks that could either lead to validation errors or maybe some sort of other error(maybe even an exception) or a success message still gets me what I should be returning.
像我需要首先做一些业务检查,可能导致验证错误或可能是某种其他错误(甚至可能是异常)或成功消息仍然得到我应该返回的东西。
So lets go first with validation. Say the user fails all these validation rules what now? I am returning a string so this won't be pretty I going to have to use csv to return all the errors and parse them out.
让我们首先进行验证。假设用户现在失败了所有这些验证规则?我返回一个字符串,所以这将不会很好我将不得不使用csv返回所有错误并解析出来。
So that just seems very bad.
所以这看起来非常糟糕。
I could first have a separate method called Validate() but now I have to remember to call this before I call CreateAnEvent(). So I don't think this is that great.
我可以先有一个名为Validate()的单独方法,但现在我必须记得在调用CreateAnEvent()之前调用它。所以我认为这不是那么好。
I am using ViewModels in my mvc project so maybe I should pass the entire viewModel to the service layer and then return this ViewModel.
我在我的mvc项目中使用ViewModel所以也许我应该将整个viewModel传递给服务层然后返回此ViewModel。
In this view model I could have a collection of Errors that I could add all these errors to as well as a string to contain a success message.
在这个视图模型中,我可以有一组错误,我可以将所有这些错误添加到一个字符串中以包含成功消息。
Once it gets returned just do a check first for errors if count is zero then assume success msg is filled.
一旦它返回,如果count为零,则首先检查错误,然后假设成功填充msg。
I am not returning the most specific type back but it would solve my problem. However I don't think the service layer should know anything about a viewModel.
我没有返回最具体的类型,但它会解决我的问题。但是,我不认为服务层应该知道有关viewModel的任何信息。
I know some people do the validation in the viewmodel but I consider that more for basic non business logic rules like is a field blank or not. I don't think I should be doing testing like I described above in a viewmodel.
我知道有些人在viewmodel中进行验证,但我认为更多的是基本的非业务逻辑规则,比如是否为字段空白。我认为我不应该像上面在viewmodel中描述的那样进行测试。
So the last option I can think of is send in the Domain Model(that would be in a viewmModel since there is a good chance I would be using it in the view) and in this Domain Model I would add a string for success messages and a collection for errors.
所以我能想到的最后一个选项是发送域模型(因为我很有可能在视图中使用它,所以它将在viewmModel中),并且在这个域模型中我会为成功消息添加一个字符串,错误的集合。
I would then return this domain model.
然后我会返回这个域模型。
So it basically same idea as using ViewModels but this time extracting out the domain model and using it.
所以它与使用ViewModel基本相同,但这次提取出域模型并使用它。
So is this the best way to do it or are there better ways?
那么这是最好的方法吗?还是有更好的方法?
1 个解决方案
#1
3
I prefer to separate my validation logic into classes of their own. The reason for this is entities can have various layers of validation. My validator classes implement the following interface:
我更喜欢将验证逻辑分成自己的类。原因是实体可以有各种验证层。我的验证器类实现以下接口:
public interface IValidator<T>
{
bool IsValid(T entity);
IEnumerable<string> BrokenRules(T entity);
}
I then inject this validator into my service. The service can then return a boolean if the method succeeds / fails. On failures the additional information contained in the 'BrokenRules' enumerable is available. I have documented this in a blog post:
然后我将此验证器注入我的服务中。如果方法成功/失败,则服务可以返回布尔值。失败时,'BrokenRules'可枚举中包含的附加信息可用。我在博文中记录了这一点:
http://blog.bobcravens.com/2010/09/the-repository-pattern-part-2/
Let me know if you have any questions. Hope this helps.
如果您有任何疑问,请告诉我。希望这可以帮助。
Bob
#1
3
I prefer to separate my validation logic into classes of their own. The reason for this is entities can have various layers of validation. My validator classes implement the following interface:
我更喜欢将验证逻辑分成自己的类。原因是实体可以有各种验证层。我的验证器类实现以下接口:
public interface IValidator<T>
{
bool IsValid(T entity);
IEnumerable<string> BrokenRules(T entity);
}
I then inject this validator into my service. The service can then return a boolean if the method succeeds / fails. On failures the additional information contained in the 'BrokenRules' enumerable is available. I have documented this in a blog post:
然后我将此验证器注入我的服务中。如果方法成功/失败,则服务可以返回布尔值。失败时,'BrokenRules'可枚举中包含的附加信息可用。我在博文中记录了这一点:
http://blog.bobcravens.com/2010/09/the-repository-pattern-part-2/
Let me know if you have any questions. Hope this helps.
如果您有任何疑问,请告诉我。希望这可以帮助。
Bob