Evil Validation pattern

We want to use Evil (Entity Validation Library) do DTO validation on UI layer. I then changed Jimmy’s pattern to use the same style as Evil. One big benefit is removing the out keyword in method, Igloo coder said using out is a procedural code smell.

Some principals for validation:

1. Domain entity should always be valid, even right after new(). ctor has to take all required fields to make a fresh created entity valid.
2. Never try to valid the entity retrieve database, instead, a data clean up should be done before app released. Or create a cc.net routine to constantly check data on those shared database?
3. Never try to positionally make a entity invalid, always try valid before making changes, not after then rollback.

       // in Organization
        public void AddEmail(Email emailToAdd)
        {
            // Before add, check duplication
            IEnumerable<string> brokenRules;

            var emailValidator = new EmailValidator(emailToAdd);
            if (!emailValidator.IsValid()) throw new ValidationException(emailValidator.ValidationErrors); 

            var dupValidator = new NoDuplicateEmailAddressValidator(_emails, emailToAdd);
            if (!dupValidator.IsValid()) throw new ValidationException(dupValidator.ValidationErrors); 

            _emails.Add(emailToAdd);
        }

    public class EmailValidator : BaseValidator
    {
        public EmailValidator(Email email)
        {

            if (new SomethingWentWrongSpec.IsSatidsiedBy(entity)
                AddValidationError("Email address has something went wrong. ");

        }

    public class BaseValidator
    {
        private IList<string> _validationErrors = new List<string>();
        public IEnumerable<string> ValidationErrors
        {
            get { return _validationErrors; }
        }

        public bool IsValid()
        {
            return ValidationErrors.Count() == 0;
        }

        protected void AddValidationError(string error)
        {
            _validationErrors.Add(error);
        }    

        protected void AddValidationErrors(IEnumerable<string> errors)
        {
            _validationErrors.Union(errors);
        }
    }
    }

I tried Specification pattern in Domain entities, it’s neat for its nice re-wrote if condition, but the native Specification can’t process error messages, so I just use the validator directly in Domain entity class.

Csla.ObjectFactory III – What’s wrong with UpdateChildren()

Derick Bailey’s post about Csla vs DDD brought out a simple but very interesting question :

Which one is correct?
Person.AddCertificate(), or Person.Certificates.Add()?

Almost the same? But it turns out the 2nd one is NOT “correct”, at least, not in DDD way.

That’s the problem in CSLA. Always thinking in table, data-centric design/dev. An extreme example, FieldManager.UpdateChildren().

How about save? Person.UpdateEmail() or Person.Email.Update(). [Email.Child_Update() in classic CSLA way.]

CSLA is not an ORM tool/framework, but BO carries all the dirty flags, in fact it’s DataPortal doing all the relationship maintenance work. RootBO.Save() is handling all the updates of its children, through FieldManager.UpdateChildren() jumping into each childBO’s internal private Child_XYZ methods. Handy, “clean”, but it’s not “correct”.This is the exactly same problem when I was trying to switch to the new Csla.ObjectFactory way: I had to keep an extra set of Protal methods in child BO, those child portal method,  to work with Parent BO’s FieldManager.UpdateChildren() method.

What if we ignore FieldManager completely? Just let Person.Save() directly call DataPortal.Update<EmailBO>(person.Email) ? Or DataPortal.Update<TelephoneBOCollection>(person.Telephones) ? Then child BO can still use  the general AbstractFactory which only have root level CRUD methods.

The direction Rocky made in ObjectFactory looks right, child CRUD should be done by root BO.  The thing is, it’s not backwards completable. It’s trying to retire FieldManager.UpdateChildren()!

The update route should be RootBO.Save -> Root Factory.Update -> Child Factory.Update, don’t call child BO’s internal Child_XYZ anymore.

Currently for legacy reason I still keep the following code in my ChildBO to bump calls from parent to child’s own factory, those UpdateChildren() in root BO can be alive for awhile, until I move them to root factory, which should be the newly strongly-typed customized UpdateChildren().

private void Child_DeleteSelf(){ DataPortal.Delete(this);}

private void Child_Insert(IParent parent){
     this.ParentId = parent.Id;
     DataPortal.Update(this);
}

private void Child_Update(){
     var newBO = DataPortal.Update(this);
     DataMapper.Map(newBO, this);
}

It might just looks like a wrapper trick, but those DataPortal calls are actually in Factory class now which indeed is in an external true service layer.

In my app, it’s one AbstractFactory for all BOs, both root and child.

I do have a problem now, where should I put transaction scope attribute? It shouldn’t be a big deal, possible solutions:

1. Create some extra methods in factory not in transaction Scope dedicated for child methods,
2. Unit of Work pattern?

Look back Ryan’s ProjectTrackerHybrid code, all the child propertis are not registered! Which means they are not in fieldmanager at all. It’s ORM’s job to handle the realationship UpSet (Update/Insert).

About Collection

If I want repository return a group of data, which type should I choose? I saw some NHibernate DAO just return IList<T>, JP’s factory pattern returns IEnumerable, Rocky’s CSLA return costomized collection.

Which one is better? After I read this post about collection, I feel the power of the DDD, this post described a typical filter problem:

public class BookCatalog {
List<Book> findBooksByAuthor( … ) {..}
List<Book> findBooksByPublisher( … ) {..}
List<Book> findBooksByAuthorAndPublisher( … ) {..}

Can be easily solve by changing method return type from List<> to costomized collection:

public class BookCatalog {
BookCatalog findByAuthor( … ) {..}
BookCatalog findByPublisher( … ) {..}
BookCatalog findByPublishDates( DateTime,DateTime ) {..}
BookCatalog findByPublishingCountry( … ) {..}

The method chain is here:

BookCatalog.findByAuthor(“Frank”).findByPublisher(“Frank Inc.”)…

The new LinQ where syntax has the similar effect.

I still don’t know why IEnumeralbe should be used, seems it’s usefule when passing data to UI / controls, but why it’s also popular in passing data from DAL to upper layers.

Validation in Domain Layer

Following JP’s demo code, I made some changes trying to make code more understandable.

1. Move Rules/RuleSet sub class out from entity class. Make it a seperate class, say MyEntityRules.
2. Re-write validate() in entity class instead of DomainObject ancestor, because my entity classes are from LinqToSql, it’s hard to intercept entity’s constructor. In this override validate(), I put code like this:
   

   return MyEntityRules.Default.BrokenBy(this);

3. Remove unused ruleset field from DomainObject, make validate() in DomainObject throw throw new NotImplementedException();

It works well in my app. It looks like I can easily create more validate method in different situation. e.g, MyEntityRules.High, MyEntityRules.Low, etc…