Yeah, that was what I was thinking about, but how do I return the null object, if what I'm looking for isn't registered?
Kenneth On Fri, Jan 6, 2012 at 01:41, Rory Plaire <[email protected]> wrote: > What about using http://en.wikipedia.org/wiki/Null_Object_pattern for a > null validator? Then you don't need to customize the factory and you also > don't have to test for null. > > -r > > 2012/1/5 Kenneth Siewers Møller <[email protected]> > >> That's exactly why i wrote in the first place :) >> >> I'm not really sure how to approach this then. The point is, that >> validation is optional. If I should adhere to the open/closed principle, I >> would think I need only to add a new class to implement the new behavior, >> correct? >> >> So basically, this is what happens: >> >> When a new message is created, it is passed to the message validation >> service. The service has a dependency on a IMessageValidatorFactory (typed). >> The validation service is calling the factory, passing the message to >> validate, which in turn is providing a validator for the specific message. >> If no validator is registered for the message (null), the service should >> just validate to true. >> >> Am I completely off here and is there a better approach? >> >> Is there a way to return a default for a service, if none is registered >> that matches the concrete one, like a DefaultMessageValidator? >> >> >> Kenneth >> >> >> >> 2012/1/5 Krzysztof Koźmic <[email protected]> >> >>> That's not something I would normally recommend but if that's what you >>> want it should be fine :-) >>> >>> K >>> >>> >>> On 05/01/2012 9:51 PM, Kenneth Siewers Møller wrote: >>> >>> Hi, >>> >>> I'm currently working on an alternative implementation of the >>> TypedFactoryComponentResolver. >>> My problem is, that I'd like to use typed factories, but I need to >>> return null, in case the component isn't registered. >>> The concrete usecase is, that I'm looking for a validator for a specific >>> type, and if no validator is registered, it should just return null from >>> the factory. >>> As the default implementation always throws an exception, if no >>> component is registered, I've created my own version. >>> >>> /// <summary> >>> /// Resolves a component. If the component isn't registered, the >>> resolver returns null instead of an exception. >>> /// </summary> >>> internal class NullSafeTypedFactoryComponentResolver : >>> TypedFactoryComponentResolver >>> { >>> public NullSafeTypedFactoryComponentResolver(string componentName, >>> Type componentType, IDictionary additionalArguments, bool >>> fallbackToResolveByTypeIfNameNotFound, Type actualSelectorType) >>> : base(componentName, componentType, additionalArguments, >>> fallbackToResolveByTypeIfNameNotFound, actualSelectorType) { } >>> >>> public override object Resolve(IKernelInternal kernel, IReleasePolicy >>> scope) >>> { >>> // Check to see if the component is registered >>> var hasComponent = componentName != null >>> ? kernel.HasComponent(componentName) >>> : kernel.HasComponent(componentType); >>> >>> return hasComponent ? base.Resolve(kernel, scope) : null; >>> } >>> } >>> >>> I'm then overriding the BuildFactoryComponent method from the >>> DefaultTypedFactoryComponentSelector, to return my own implementation. >>> >>> Since I'm doing something non-standard, I'd just wanted to make sure, >>> I'm not misusing (or misunderstanding) the concept of a typed factory. >>> Basically I'm changing the semantics of the container, so I'm just a bit >>> uncertain about which implications it may bring. >>> >>> >>> Thanks, >>> Kenneth >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Castle Project Users" group. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msg/castle-project-users/-/GW3SaUL8FTEJ. >>> To post to this group, send email to >>> [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/castle-project-users?hl=en. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Castle Project Users" group. >>> To post to this group, send email to >>> [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/castle-project-users?hl=en. >>> >> >> >> >> -- >> Med venlig hilsen / Kind regards >> Kenneth Siewers Møller >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Castle Project Users" group. >> To post to this group, send email to >> [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/castle-project-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-users?hl=en. > -- Med venlig hilsen / Kind regards Kenneth Siewers Møller -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
