.NTier support

Mar 19, 2010 at 2:59 PM

You have in your documentation among others Custom Rules and Custom Validators. As you know some validations require Database Access, which is not available if the code is executed on the client Tier. What I'm missing in your framework is a filter function. ValidationCatalog.Register<MyFilterClass>(myFilter).The filter method should executed during a validation process. All the Rules instances should be passed to the method, you are going to execute during a validation process. It's up to the filter method to decide, which rules should be executed and which not (maybe based on a class attribute). This depends on where the code is executed on client or on server. So we would be able to validate the most things on the client side, without to have to pass all the objects to the server tier.

To my opinion this is not the idea of a ValidationContext or Specification. Therefore to create RemoteSpecification or RemoteContext is not really an option for me.

ValidationResult actually contains the reference to the class. I our case, is just the class full name important, otherwise we would have to serialize the ValidationResult including the classes containing broken rules. I a rule is broken we should be able to create our own IValidationResult and return it to the framework. Please consider that in this case the IValidationResult is an Interface.

Kind regards,



Mar 19, 2010 at 9:15 PM

I'm not sure I understand completely the architecture you're trying to apply SpecExpress. Is your client a Silverlight, Web, or something else? Are you using Domain objects or DTO's in your client layer?

Mar 19, 2010 at 9:42 PM

We are developing using Domain Driven Design. Our Entity Objects are transfered over tiers. Therefore I would have to implement a T4 template which generates POCO objects for Entitiy Framework and hopefully also Validation Classes for your SpecExpress Framework. These default Save RuleValidators would just be classes which are checking required values, the lenght, nullable types and so on. The values are generated from the database schema. For the client we are using the MVVM Pattern and the client could be Silverlight, ASP.Net and WPF Rich Application. Actualy its a WPF Rich client. We want to prevent to have to much communication to the server for validation purposes. All Validation and Entity classes are also available on the client side. 100% the same assemblies. We have proxies only for long running processes, messaging, sessionmanagement, CRUD, workflows and so on on the server side.

So we have to be able to make a difference between local running Validations and remote running Validations (with database access). I the background its just one flag, which determines if it is NTier application or just Client Server application. We set that flag depending on the customer size and contract with the customer.

Mar 19, 2010 at 10:11 PM
Edited Mar 19, 2010 at 10:45 PM

An other better option were if you would create an attribute called


which can be set on customer RuleValidator. All your validations contained in the framework can always be executed on the client.

ValidationCatalog may have a Property

ValidationCatalog.ValidationTierLocal = true/false

If ValidationCatalog.ValidationTierLocal = true then just execute all RuleValidators with ValidationTierRunLocal attribute
If ValidationCatalog.ValidationTierLocal = false then execute all RuleValidator independent of the attribute. This is the default behaviour.

Do you understand the Idea behind this concept?

Kind regards,





Mar 21, 2010 at 4:24 PM

If I understand you correctly, the end goal you are trying to achieve is a way of defining which rules should be enforced at the client and which at the server such that the client would not have to evaluate rules the cause an out of process call.  Correct?

I know that you mentioned in your first message that you don't see this as the functionality of the ValidationContext.  However, I think you may want to reconsider and explore combining a ValidationContext in combination of the "Using" method in your specifications.  You could easily create a client side specification that is used in the server side specification (by leveraging the Using method in your server side specification).  Then enroll each specification in a ServerSide context or a ClientSide context.

BTW: If your server side specifications are having to make calls to a database causing the assembly your specifications are defined in is having to reference System.Data, AND your intent is to leverage the specifications assembly in a Silverlight client in the future, you may have a problem.  This is because Silverlight does not support ADO.Net.  To get around this, you will want to consider putting all your client side specifications in their own assembly and reference it from the server side assembly.

Happy programming!


May 7, 2010 at 7:26 PM

Thanks a lot for your suggestions. I will solve it as you described it above. Actually I have the problem, that I'm not able to serialize your classes:

  • ValidationNotification
  • ValidationResult
  • ValidationException

Could you please mark them as Serializable using the [Serializable] Attribute on the class level?

Thanks, Marinko