Important changes to SharpArch.Core and new capabilities

[Billy]

You're either going to love these changes or your going to hate them,
but they're going to be in the beta release either way. ;) These
changes have been done to simplify the object model, to make the
language and organization more in line with domain driven design, and
to provide a couple more conveniences for development.

* SharpArch.Core is now mainly organized within two namespaces, along
with noted changes as follows:

/SafeServiceLocator.cs: Provides a more informative means for
accessing dependencies from the Common Service Locator than just
invoking ServiceLocator directly.

/DomainModel
/BaseObject.cs: Provides basic object comparative services.
/Entity.cs: This replaces DomainObject.cs and PersistentObject.cs,
which have both been deleted, and provides an object with a domain
signature and a typeable ID property. This also has the validation
support of NHibernate Validator. Objects which extend from Entity
MUST have at least one [DomainSignature] property; it'll throw a
Design-By-Contract exception if this is violated. The interface
IEntityWithTypedID allows you to roll your own.
/ValueObject.cs: This is a value object wherein all of its
properties are used when compared to another value object. Objects
which extend from ValueObject may not have any [DomainSignature]
properties; it'll throw a Design-By-Contract exception if this is
violated.

/PersistenceSupport
/IEntityDuplicateChecker.cs: Provides an interface for a behavior
specific repository which looks for a duplicate entry of an entity
/NHiberanateValidator
/HasUniqueDomainSignatureValidator.cs: Provides a class level
attribute which can placed on an Entity to validate whether or not the
entity has an existing entry in the database using the DomainSignature
properties. I've included a sample further below.

* SharpCore.Data hasn't changed outside of the following addition:

/NHibernate
/EntityDuplicateChecker.cs: Provides a concrete implementation for
the associated interface in SharpArch.Core.

To use the entity duplicate validator, you just need to do two things:

1) Add the following line to YourProject.Web/CastleWindsor/
ComponentRegistrar.AddGenericRepositoriesTo() method:

container.AddComponent("entityDuplicateChecker",
typeof(IEntityDuplicateChecker), typeof
(EntityDuplicateChecker));

2) Add the [HasUniqueDomainSignature] above your entity class
declaration and it'll automatically check, when IsValid() or
GetValidationMessages() is invoked, whether another entity already
exists having the same domain signature properties (taking into
account the ID when appropriate). An example object follows which
will check the database for another employee having the same
SocialSecurityNumber:

[HasUniqueDomainSignature]
public class Employee : Entity
{
public Employee() { }

[DomainSignature]
[NotNull, NotEmpty]
public virtual string SocialSecurityNumber { get; set; }

[NotNull, NotEmpty]
public virtual string LastName { get; set; }
}

These changes are very easy to accommodate within your own code after
putting into place the latest SharpArch libraries:
1) Do a solution wide find and replace of "PersistentObject" with
"Entity"
2) Change every call to ".ValidationMessages" to
".GetValidationMessages()"
3) Add "using SharpArch.Core.DomainModel;" onto every page having a
reference to Entity. Let the compiler tell you where you need them
and ReSharper to help you add them in.

I hope you find these changes useful and beneficial for the
development of S#arp Architecture applications. The VS template and
scaffolding support has been updated to reflect these changes as well
as the sample Northwind code. The documentation is mostly up to date
but I'm aware of a couple of existing bugs in the tutorial...will be
addressing those soon.

Billy McCafferty

[Luis Abreu]

It looks like I will have to resort to copy/paste again to update my base
classes, right?

[Billy]

Assuming you do not want NHibernate Validator, you'll likely want to
roll your own Entity base class implementing IEntityWithTypedId<>.
That is why the interface exists (along with IValidatable).
Furthermore, it's very little that you'll have to implement assuming
you want NHibernate Validator out of your Entity class; take a look at
the existing http://sharp-architecture.googlecode.com/svn/trunk/src/SharpArch/SharpArch.Core/DomainModel/Entity.cs.
The only methods you'll need to implement are
GetTypeSpecificSignatureProperties() and Equals().

I'd like to put the NHibernate Validator issue to rest. It's going to
be in the release Luis.

Billy

[Luis Abreu]

>
> Assuming you do not want NHibernate Validator, you'll likely want to
> roll your own Entity base class implementing IEntityWithTypedId<>.
> That is why the interface exists (along with IValidatable).

Yes I can do that. But am I the only one to see something wrong with the
architecture of the current core assembly? Whenever I think at a domain
assembly, I'm thinking at a domain which has the main domain concepts and
that tries to be as "pure" as possible (where pure means that it doesn't
have unneeded dependencies on other assemblies).

The decision of using NH validator means that the base core domain assembly
has a dependency which shouldn't really be there. And more: after looking at
NH validator assembly, it looks like it depends on the NH assembly. When
you think about reuse of the domain assemblies across tiers (something which
you know I'm not really a fan of), this means that the only way to reuse the
core s#arp assembly is when you're using NH. And even in those scenarios,
the final result is not good. Suppose you're using windows forms UI and you
want to reuse the domain assemblies (bad thing, but again, probably ok for
small domain/scenarios). What does that mean in the current release? It
means you have to deploy your domain assemblies, the core S#arp, nh
validator and nh assembly itself...now, if you're using windows forms in a
distributed app (which is something I've ended up doing several times),
there really is a great probability of using services for encapsulating db
access. Now, in that case, why must I also redistribute NH and NH validator
if my service already encapsulates that stuff? See where I'm going wiht
this?

And what happens when you're not using NH? You have several cool classes and
a pretty good domain hierarchy which probably won't get used because if
you're not using NH for persistency, why do you need to reference it and NH
validator assmbly in your custom domain assemblies?

Ok, you can say that the objective of this project is to build some domain
classes for using with NH. I can't do anything about that but is it that
hard to give the next step and have something useful for any db access
technology? I believe not, but, as you said, you're the one in charge so
it's really your decision.

As I said, nothing would make me happier than to simply drop the core s#arp
assembly into my projects and reuse the base classes. With the current
release, this is not doable due to the reasons I've presented earlier.

Now, I hope you don't get me wrong. I don't want to upset anyone. I'm just
trying to have a base assembly I can use anywhere I apply domain driven
design.

And yes, this is my last post on this topic.

Thanks :)

Luis

[Billy]

Luis,

Your comments on this matter are duly noted.

Billy

[Luis Abreu]

Ok.

I won't bring them here again...promise :)

> -----Original Message-----
> From: sharp-arc...@googlegroups.com [mailto:sharp-
> archit...@googlegroups.com] On Behalf Of Billy

[Kyle Baley]

Actually, I wouldn't mind bringing the discussion up again because it seems like Billy and Luis are the only ones having any fun in it. I've been ignoring the validation threads to date but have just caught up on them. Here is my understanding of the two sides:

 

- We don't want to complicate the domain hierarchy with multiple layers. Validation support should be as close to the domain as possible

- We don't want to tie our domain to NHibernate.Validator (and by extension, NHibernate itself)

 

Assuming that is accurate, both sound reasonable. But by the same token, they don't sound mutually exclusive. I haven't done a whole lot on validation frameworks (usually hard-coding it in my domain because I'm lazy) but I can't imagine this problem hasn't been addressed in some form or another. Can't the domain rely on interfaces (or, I suppose, abstract base classes) and we ship with an NHValidator implementation that can be swapped out? Or do the attributes get in the way of this? Are attributes even the way to go?

Would like to hear from someone other than Billy or Luis if possible.

[DavidHayden]

If it helps, I have an MVC Architecture where I abstracted out the
validation using a few classes:

IValidatable - Optional Signal that Entity Supports Validation
ISelfValidatable - Optional Signal that Entity Validates Itself
IValidator<T> - Provider
ValidationResults - Immutable Collection of ValidationResult Classes
plus an IsValid Property
ValidationResult - Immutable Validation Error with Key and Message
Properties
ValidationException - Immutable Exception with an additional Results
Property that holds ValidationResults



If you are familiar with the Enterprise Library Validation Application
Block, some of these classes are similarly named to what you will find
in the VAB. I mainly use the VAB, but didn't want to have the
dependency on the library in cases where I couldn't or didn't want to
use it.

Now one can inject IValidator<T> through DI, obtain the validator
through a call to a service locator, or do validation in a Repository
Decorator and throw a ValidationException.

You can download the EntLib Source if you are interested in using
their classes for inspiration, which is what I did.

After all is said and done, I still haven't used any other validation
framework other than the VAB with this framework so I can't say this
abstraction was a big deal yet. Mainly warm fuzzies I guess in that I
don't have infrastructure concerns in my domain. However, there is
something to be said about the ease-of-use, simplified architecture,
and possible performance gains with regards to opinionated frameworks
that you guys are attempting to develop here. Abstraction has it price
but you never hear about that in too many discussions ;)


Best Regards,

Dave

> > > > Luis- Hide quoted text -
>
> - Show quoted text -

[Bobby Johnson]

Hi Kyle,

One possibility is to wrap NHibernate.Validator in an ISpecfication<T> interface. Looking at NHib.V in reflector it appears that each attribute has a corresponding Validator. So the interface might look like...

ISpecification<T>
{
IsSatisfiedBy(T item)
IList<ISpecViolation> Messages

--
"The explanation requiring the fewest assumptions is most likely to be correct."

- Occam's Razor
http://en.wikipedia.org/wiki/Occam's_Razor

[DavidHayden]

On another note, there may be a good reason to abstract out the
validation provider based on the other thread happening here on Client
Side Validation:

http://groups.google.com/group/sharp-architecture/browse_thread/thread/d16c78472c3eef02


One of the things I really like about the Validation Application Block
in Webforms was the ASP.NET Integration they provided via the
PropertyProxyValidators. This allowed the UI to use the same
validation on the server-side without duplicating the validation
rules. I did a post a long time ago on it here:

http://davidhayden.com/blog/dave/archive/2007/02/14/ValidationApplicationBlockASPNETWebsiteIntegration.aspx


The WCSF Team went ahead and created a way to do this without a
postback using AJAX with the ServerSideValidationExtender:

http://www.pnpguidance.net/Post/ServerSideValidationExtenderASPNETServerSideValidationAJAXPartialPagePostBack.aspx


I can't tell you how invaluable this is from a validation standpoint.

Inevitably developers will want this synchronized client and server-
side validation in the MVC Framework either via something like xVal or
a validation framework directly. By directly coupling to NHiberante
Validator, one might lose out on the chance to implement xVal or a
validation framework that might give this much needed functionality.


Just a thought.

Regards,

Dave

> - Occam's Razorhttp://en.wikipedia.org/wiki/Occam's_Razor- Hide quoted text -

[Billy]

This is becoming a much more productive discussion than Luis and I's
No-Yes-No-Yes ping pong session. ;)

I don't mind introducing abstraction to allow various validation
mechanisms; but I also want validation ingrained enough to make the
validation mechanism opinionated. What do you all think about
creating interfaces similarly to what was done for the Common Service
Locator? Accordingly, adapters could be written for various vendors,
similar to what is done within CommonServiceLocator.WindsorAdapter.
It could be called something like "CommonValidator."

Bobby proposed ISpecification; alternatively, I really like Mr.
Hayden's solution but to simplify it for the sake of ease of
adaptation for external vendors:

IValidatable - Signal that Entity Supports Validation (only used
within S#arp Architecture; not part of CommonValidator)
+ bool IsValid()
+ IEnumerable<IValidationResult> ValidationResults()

IValidator - Implemented by third party vendor adapters or by custom
implementations
+ bool IsValid(object)
+ IEnumerable<IValidationResult> ValidationResultsFor(object)

IValidationResult - A validation result
+ object ApplicableTo (could contain a property name, a class name,
PropertyInfo, an enumeration of PropertyInfo; whatever the vendor
deems as the target of the validation result)
+ string Message

David and others, do you think that a "CommonValidator" would be
warranted and supported? (And, if so, what do you think it should
look like?)

Billy

On Jan 14, 10:14 am, DavidHayden <davehay...@gmail.com> wrote:
> On another note, there may be a good reason to abstract out the
> validation provider based on the other thread happening here on Client
> Side Validation:
>

> http://groups.google.com/group/sharp-architecture/browse_thread/threa...

>
> One of the things I really like about the Validation Application Block
> in Webforms was the ASP.NET Integration they provided via the
> PropertyProxyValidators. This allowed the UI to use the same
> validation on the server-side without duplicating the validation
> rules. I did a post a long time ago on it here:
>

> http://davidhayden.com/blog/dave/archive/2007/02/14/ValidationApplica...

>
> The WCSF Team went ahead and created a way to do this without a
> postback using AJAX with the ServerSideValidationExtender:
>

> http://www.pnpguidance.net/Post/ServerSideValidationExtenderASPNETSer...

> > - Occam's Razorhttp://en.wikipedia.org/wiki/Occam's_Razor-Hide quoted text -

[Luis Abreu]

I’m just sending this to say  that this resume seems correctJ

 

<br

[Bobby Johnson]

I like the idea and would like to subscribe to your news letter. 8)

[Billy]

I believe that I've checked in changes that will bring this to a final
resolution (and get us one step closer to releasing 1.0 beta this
week).

I have made the following modifications to SharpArch.Core which
abstracts NHibernate Validator away from the SharpArch libraries so
that any validation mechanism may be leveraged:

* Added SharpArch.Core/CommonValidator/ containing:
- IValidatable.cs: Indicates that the object is validatable
- IValidationResult.cs: Holds validation results for a single class
or property
- IValidator.cs: Provides a "Common Service Locator" equivalent for
validation frameworks and/or adapters to be plugged into S#arp
Architecture

* Added a new class library called SharpArch.Core.NHibernateValidator
containing:
- /CommonValidatorAdapter/*.cs: Concrete classes for an adapter for
NHibernate Validator
- HasUniqueDomainSignatureValidator.cs: This was previously in
SharpArch.Core/NHibernate/Validator but now has a new home in this
specialized class library

To use, you simply need to add your Validator service component
(implementing IValidator) to your IoC. By default, the VS template
will be modified to include the NHibernate Validator mechanism.

Here were the modifications I just made to the Northwind sample code
to accommodate this abstracted validation mechanism:

1) Within Northwind.Core, Northwind.Web and Northwind.Tests, added a
reference to SharpArch.Core.NHibernateValidator
2) Did a solution-wide find and replace of "using
SharpArch.Core.PersistenceSupport.NHibernateValidator;" with "using
SharpArch.Core.NHibernateValidator;"
3) Did a solution-wide find and replace of "using
SharpArch.Web.NHibernate.Validator;" with "using
SharpArch.Web.CommonValidator;"
4) Did a solution-wide find and replace of ".GetValidationMessages()"
with ".ValidationResults()"
5) Did a solution-wide find and replace of ".ValidationResults
().Length" with ".ValidationResults().Count"
6) Added a class to Northwind.Tests called ServiceLocatorSetup with a
single method to add the Validator adapter to the CSL
7) Added a call to ServiceLocatorSetup.InitServiceLocator(); in
appropriate unit tests which need access to the IValidator service
8) Within Northwind.Web.CastleWindsor.ComponentRegistrar, added a
component for the IValidator interface

Any and all feedback on this would be most appreciated. I very much
intend to release S#arp Architecture 1.0 Beta this week and would like
to pin down support for server side validation once and for all. (I
have not yet made these changes to the VS template which I will do
after getting feedback on the changes.)

Billy McCafferty

On Jan 14, 11:35 am, Bobby Johnson <bobby.john...@gmail.com> wrote:
> I like the idea and would like to subscribe to your news letter. 8)
>

> > > > - Occam's Razorhttp://en.wikipedia.org/wiki/Occam's_Razor-Hide<http://en.wikipedia.org/wiki/Occam%27s_Razor-Hide>quoted text -

[Martin Hornagold]

Billy,

Fantastic. Can't wait to have a look at it.
Thanks for listening and reacting, as like Luis this issue would have become a stumbling block for me.

[Luis Abreu]

Thanks!

I still haven't looked at the code, but it seems like now I can really reuse
these assemblies in all my projects.

Luis

> -----Original Message-----
> From: sharp-arc...@googlegroups.com [mailto:sharp-
> archit...@googlegroups.com] On Behalf Of Billy
> Sent: quinta-feira, 15 de Janeiro de 2009 09:11
> To: S#arp Architecture

> Subject: Re: Abstracted Validation within S#arp Architecture
>
>

[Bobby Johnson]

Awesome, thanks Billy.

[Jay Oliver]

Out of curiosity, do you think it will be possible to allow for the
use of automapping in the 1.0 release? I'm not sure where Kyle is with
his experiment, but it seems to me that this would be a pretty minor,
non-breaking change. I think all you essentially would need to do
would be provide an overload of NHibernateSession.Init() that takes an
AutoPersistenceModel (or PersistenceModel), instead of an array of
assembly names, that is used to configure the NHibernate Configuration
object.

I'm not sure if taking in an IPersistenceConfigurer would be useful or
not too, all of the concrete types have a Dictionary<string, string>
ToProperties() method so it probably doesn't matter.

> ...
>
> read more »

[Kyle Baley]

An Init overload is all that is necessary for the #arch project. I was also playing with updating the Northwind sample which was more involved.

 

One of the issues I had though was how best to support both ClassMaps and auto persistence. Here is what I ended up doing to the NHibernateSession class to support it (changes in bold):

 

        private static void AddMappingAssembliesTo(Configuration cfg, ICollection<string> mappingAssemblies, AutoPersistenceModel mappings) {
            Check.Require(mappingAssemblies != null && mappingAssemblies.Count >= 1,
                "mappingAssemblies must be provided as a string array of assembly names which contain mapping artifacts. " +
                "The artifacts themselves may be HBMs or ClassMaps.  You may optionally include '.dll' on the assembly name.");

            foreach (string mappingAssembly in mappingAssemblies) {
                string loadReadyAssemblyName = (mappingAssembly.IndexOf(".dll") == -1)
                    ? mappingAssembly.Trim() + ".dll"
                    : mappingAssembly.Trim();

                Assembly assemblyToInclude = Assembly.LoadFrom(loadReadyAssemblyName);
                // Looks for any HBMs
                cfg.AddAssembly(assemblyToInclude);
                if (mappings == null)
                {
                    // Looks for any Fluent NHibernate ClassMaps
                    cfg.AddMappingsFromAssembly( assemblyToInclude );
                }
                else
                {
                    mappings.addMappingsFromAssembly( assemblyToInclude );
                    cfg.AddAutoMappings( mappings );
                }
            }
        }

This also requires that your ClassMaps derive from AutoMap<T> instead of ClassMap<T>. Not being familiar with Fluent NHibernate, I'm not entirely sure this is the correct way to do it. This did allow me to remove the CategoryMap completely and to include a CustomerMap that had only the lazy loading set (using conventions for everything else). But I had trouble stripping down the EmployeeMap to override the conventions for the HasManyToMany part. If someone else wants to take a look, I've included the patch of my work.

[Billy]

You owe me a beer Luis. ;)

Billy

> ...
>
> read more »

[Billy]

Yes, with the work Kyle's been sharing, this looks like it'll make it
in. If you will, please review the patch that Kyle provided and give
your feedback.

Thank you,
Billy

> ...
>
> read more »

[Jay Oliver]

Sure, I'd be happy to check it out.

Kyle, could you provide provide the new and changed assemblies
somewhere?

> ...
>
> read more »

[Jay Oliver]

I think I've pieced together the binaries I need from the trunk of
FluentNhibernate and the inflection library I was able to track down
on the web.

I'm starting to look into this, and so far it seems pretty good,
although none of the tests that need to connect to a database work
because there's currently no way to tell the fixture base classes to
use the auto mappings. I'll see if anything springs to mind for an
easy way to handle that.

I did run into one thing I'd like to ask about however - using the
NHibernateSession class, it doesn't seem like there's any way to not
have a configuration file. Is there a specific reason for this? I'd
love to be able to provide a FluentNHibernate IPersistenceConfigurer
or a property dictionary instead.

[DavidHayden]

The validation look good! As a proof of concept I created a validator
for Enterprise Library that will work. I will dump this up on
PnPGuidance.net for download later:


public class EntLibValidator : IValidator
{
public bool IsValid(object value)
{
Check.Require(value != null, "value to IsValid may not be
null");

return DoValidation(value).IsValid;
}

public ICollection<IValidationResult> ValidationResultsFor(object
value)
{
Check.Require(value != null, "value to ValidationResultsFor
may not be null");

var errors = DoValidation(value);

return CollectionOf(errors);
}

protected virtual ValidationResults DoValidation(object value)
{
var factory = ValidationFactory.CreateValidator(value.GetType
());
return factory.Validate(value);
}

protected static ICollection<IValidationResult> CollectionOf
(IEnumerable<ValidationResult> errors)
{
var results = new List<IValidationResult>();

foreach (var error in errors)
results.Add(new ValidatorResult(error));

return results;
}
}


public class ValidatorResult : IValidationResult
{
public Type ClassContext { get; protected set; }
public string PropertyName { get; protected set; }
public string Message { get; protected set; }

public ValidatorResult(ValidationResult result)
{
Check.Require(result != null, "result may not be null");

ClassContext = result.Target.GetType();
PropertyName = result.Key;
Message = result.Message;
}
}


Regards,

Dave

On Jan 15, 4:10 am, Billy <googlegro...@emccafferty.com> wrote:

> ...
>
> read more »- Hide quoted text -

[Luis Abreu]

> You owe me a beer Luis. ;)
>

yep...in fact, I'll pay you 2, ok?

--
Regards,
Luis Abreu

[Jay Oliver]

From the application side, this is looking pretty solid so far.

Integrating it into the Test Fixture base classes will take a bit of
work. I think there will have to be a way to push the filters/
conventions in rather than pulling the data from a file specified in
the appSettings the way the mapping assemblies are pulled in now, as
the expressions involved can't easily be boiled down to something that
lives in a config file.

I'm not sure what the best way to let this data get injected into the
framework. Perhaps some virtual methods could be added to
DatabaseRepositoryTestsBase, RepositoryTestsBase and
RepositoryBehaviorSpecificationTestsBase that would allow each
application to provide their own base classes that configure the
automapping before the NH config and database is initialized.

Kyle, have you spent any time on this yet? I don't want to be
duplicating effort.

[Jay Oliver]

Is there any reason the mappings and NH cfg need to be rebuilt every
repository test? I think those are relatively expensive operations,
and it doesn't seem like there's any way the outcome could change
without editing the configuration file in the current version.

[Billy]

Jay,

Correct me if I'm wrong, but if it's not rebuilt, the in-memory
database will persist data from one unit test to another.
Accordingly, depending on the order that the unit tests run could
corrupt "later" tests with data that's still sitting around the in-
memory DB.

But you're right that it's expensive and noticeable. My current
project (built on S#arp Architecture) has 225 tests but only 19 of
which communicate with the in-memory SQLite. These DB tests take
about 8 seconds to run while the remaining 206 only take about 3.5
seconds to run.

To you have ideas as to how the database could be cleared, without
necessarily being rebuilt before each test?

Thanks!
Billy

[Jay Oliver]

Bill,

My understanding is that each new connection will create a new in-
memory database, so all you should need is to guarantee each test gets
a new session. The configuration, sessionfactory and eventually
AutoPersistenceModel should be fine to keep around between tests.

FWIW, this is why it's necessary to set connection.release_mode to
on_close and make sure the SchemaExport runs on the same session that
the tests do.

[Jay Oliver]

I whipped up a quick proof of concept, and it does seem to run the
tests in Northwind successfully and noticeably faster. I'll mail you
the patch, since I can't seem to find a way to attach it in the google
groups interface.

However, I did run into a problem with the approach I took - the
MappingIntegration tests reinit the session, causing all subsequent
tests in that run to fail.

I implemented a really naive temporary fix for this so you can just
drop it in and see how much faster it makes your project, but I'm sure
you can come up with a better way to do it.

[Kyle Baley]

I haven't done any work outside of the patch I sent a couple of days ago.

 

Re: sending patches to Google groups. i do it by sending an e-mail to sharp-arc...@googlegroups.com. It's how I post to the group in general.

[Jay Oliver]

Ok. Starting with your patch, I'll see what I can come up in regards
to getting automapping running with the unit tests.

On Jan 16, 8:52 am, Kyle Baley <k...@baley.org> wrote:
> I haven't done any work outside of the patch I sent a couple of days ago.
>
> Re: sending patches to Google groups. i do it by sending an e-mail to
> sharp-arc...@googlegroups.com. It's how I post to the group in
> general.
>

[BringerOD]

IValidator<T>

I am trying to figure out how to have a custom for some of the
entities within this architecture.

container.AddComponent("validator", typeof (IValidator), typeof
(Validator));

How would I override this for multiple entities?

> > abstracts NHibernateValidatoraway from the SharpArch libraries so

> > that any validation mechanism may be leveraged:
>
> > * Added SharpArch.Core/CommonValidator/ containing:
> >   - IValidatable.cs:  Indicates that the object is validatable
> >   - IValidationResult.cs:  Holds validation results for a single class
> > or property
> >   - IValidator.cs:  Provides a "Common Service Locator" equivalent for
> > validation frameworks and/or adapters to be plugged into S#arp
> > Architecture
>
> > * Added a new class library called SharpArch.Core.NHibernateValidator
> > containing:
> >   - /CommonValidatorAdapter/*.cs:  Concrete classes for an adapter for
> > NHibernateValidator
> >   - HasUniqueDomainSignatureValidator.cs:  This was previously in

> > SharpArch.Core/NHibernate/Validatorbut now has a new home in this
> > specialized class library
>
> > To use, you simply need to add yourValidatorservice component

> > (implementing IValidator) to your IoC.  By default, the VS template
> > will be modified to include the NHibernateValidatormechanism.
>
> > Here were the modifications I just made to the Northwind sample code
> > to accommodate this abstracted validation mechanism:
>
> > 1) Within Northwind.Core, Northwind.Web and Northwind.Tests, added a
> > reference to SharpArch.Core.NHibernateValidator
> > 2) Did a solution-wide find and replace of "using
> > SharpArch.Core.PersistenceSupport.NHibernateValidator;" with "using
> > SharpArch.Core.NHibernateValidator;"
> > 3) Did a solution-wide find and replace of "using
> > SharpArch.Web.NHibernate.Validator;" with "using
> > SharpArch.Web.CommonValidator;"
> > 4) Did a solution-wide find and replace of ".GetValidationMessages()"
> > with ".ValidationResults()"
> > 5) Did a solution-wide find and replace of ".ValidationResults
> > ().Length" with ".ValidationResults().Count"
> > 6) Added a class to Northwind.Tests called ServiceLocatorSetup with a

> > single method to add theValidatoradapter to the CSL

> > > > > > One possibility is to wrap NHibernate.Validatorin an ISpecfication<T>

> > > > > > interface. Looking at NHib.V in reflector it appears that each
> > > > attribute has

> > > > > > a correspondingValidator. So the interface might look like...

>
> > > > > > ISpecification<T>
> > > > > > {
> > > > > > IsSatisfiedBy(T item)
> > > > > > IList<ISpecViolation> Messages
>
> > > > > > }
> > > > > > On Wed, Jan 14, 2009 at 7:10 AM, Kyle Baley <k...@baley.org> wrote:
> > > > > > > Actually, I wouldn't mind bringing the discussion up again because it
> > > > seems
> > > > > > > like Billy and Luis are the only ones having any fun in it. I've been
> > > > > > > ignoring the validation threads to date but have just caught up on
> > > > them.
> > > > > > > Here is my understanding of the two sides:
>
> > > > > > > - We don't want to complicate the domain hierarchy with multiple
> > > > layers.
> > > > > > > Validation support should be as close to the domain as possible

> > > > > > > - We don't want to tie our domain to NHibernate.Validator(and by

> > > > > > > extension, NHibernate itself)
>
> > > > > > > Assuming that is accurate, both sound reasonable. But by the same
> > > > token,
> > > > > > > they don't sound mutually exclusive. I haven't done a whole lot on
> > > > > > > validation frameworks (usually hard-coding it in my domain because
> > > > I'm lazy)
> > > > > > > but I can't imagine this problem hasn't been addressed in some form
> > > > or
> > > > > > > another. Can't the domain rely on interfaces (or, I suppose, abstract
> > > > base
> > > > > > > classes) and we ship with an NHValidator implementation that can be
> > > > swapped
> > > > > > > out? Or do the attributes get in the way of this? Are attributes even
> > > > the
> > > > > > > way to go?
> > > > > > >  Would like to hear from someone other than Billy or Luis if
>

> ...
>
> read more »