If you have an interceptor that runs before your handler, wouldn't that
validation take place inside the same session that would later be used for
the handler? So if you do the validation by calling ISession.Get(), it
would be in the first level cache and no need to worry about the cache part.
But is it important to have it run _before_ the handler? The attribute in
your example is in the command definition, so it would not be immediately
obvious in the handler code that it's ok to skip the validation there,
which could be somewhat confusing I guess.
If it's ok to let the handler do the validation, how about calling
something like this instead of Get:
var customerType = _session.Require<CustomerType>(cmd.customerTypeId)
public static T Require<T>(this ISession session, object id)
{
T entity = session.Get(id);
if (entity == null)
throw something;
return entity;
}
Come to think about it, I wonder why I'm not already doing this in my
applications. I'm gonna have to look into that.
Of course, session.Load() already does something similar except the
validation won't happen until you actually try to use the entity.
Perhaps we should add the Require() method to NHibernate itself.
/Oskar
2016-08-02 15:13 GMT+01:00 Mark Perry <[email protected]>:
> Hi
>
> I have been working with NH for some years now and have seen a pattern
> emerging in my code that I'd like to see if there is a better way of
> handling.
>
> Most of my "service/handler" classes do stuff like this:
>
> public class CreateCustomerCommandHandler: IHandleCommand<
> CreateCustomerCommand>{
>
> private ISession _session;
>
> public CreateCustomerCommandHandler(ISession session){
> _session = session;
> }
>
> public void Handle(CreateCustomerCommand cmd){
> var customerType = _session.Get<CustomerType>(cmd.customerTypeId);
> var customerSex = _session.Get<CustomerSex>(cmd.customerSexId);
> var client = _session.Get<Client>(cmd.ClientId);
> //More entity loads here
>
> if(customerType == null)
> throw new NotFoundException($"CustomerType not found with id of
> {cmd.customerTypeId}");
>
> //More checks for null here
> }
>
> }
>
> What I would like to do is to check an Entity Id Cache of some sort before
> the code reaches my "Handler" classes. That way I know whether the entity
> is in the DB before I run my handler code.
>
> Think of it like Validation for entities existing.
>
> I could then implement a CommandInterceptor which does the Id validation
> before passing off to the CommandHandler.
>
> public class CreateCustomerCommand: ICommand{
> [EntityCache(typeof(CustomerType))]
> public customerTypeId {get;set;}
> //etc...
> }
>
>
>
> I know the second level cache exists and I can cache entities in that
> which does kinda give me what I want (with the benefit that when I do the
> load in the Handler no need to go to the DB).
>
> I just wondered if there was another pattern or feature of NH I was
> missing in order to achieve what I am trying to do?
>
> Any thoughts would be greatly appreciated.
>
> Thanks, Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "nhusers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at https://groups.google.com/group/nhusers.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/nhusers.
For more options, visit https://groups.google.com/d/optout.
