Gmail Calendar Documents Reader Web more »
Recently Visited Groups | Help | Sign in
Google Groups Home
S#arp Architecture
Home
S#arp Wiki
Files
About this group
Apply for group membership
Version 0.8.0 with MVC Preview 5, NH 2.0 and Ninject 1.0 now available!
Options
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
   Messages 1 - 25 of 55 - Collapse all  -  Translate all to Translated (View all originals)   Newer >
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Billy  
View profile  
 More options Oct 1 2008, 1:08 am
From: Billy <googlegro...@emccafferty.com>
Date: Tue, 30 Sep 2008 22:08:04 -0700 (PDT)
Local: Wed, Oct 1 2008 1:08 am
Subject: Version 0.8.0 with MVC Preview 5, NH 2.0 and Ninject 1.0 now available!
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
After a long delay, I finally have 0.8 available for download which
includes the official release of S#arp Architecture using MVC Preview
5, NHibernate 2.0 and Ninject 1.0.

Here is a summary of some of the more significant changes (some
breaking changes) in this release:
* Documentation has been completely updated and much new content has
been added
* ProjectBase has been renamed to SharpArch
* Ninject is now the official mechanism for performing dependency
injection
* The Equals/GetHashCode has been overhauled to be much faster;
additionally, it no longer sees a transient and persistent object as
being the same if their domain signatures are the same
* The basic Equals/GetHashCode logic has been pulled up into the
abstract class SharpArch.Core/DomainSignatureComparable.cs; this may
be used as a base class for non-persistent domain classes to provide
consistent Equals/GetHashCode behavior, e.g. an Address object mapped
as a component of an Employee
* Unit tests have been added to the SharpArch solution; it's not
comprehensive yet, but it's a start

I feel that this is the first major release with a codebase which will
no longer be changing much. Most of the changes which will be coming
in future releases will be upgrades to third party components such as
ASP.NET MVC and NHibernate, inclusion of support for new areas of
functionality such as WCF, and more sample code.  So it is my
intention that future releases will have very few breaking changes.

Billy McCafferty


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Discussion subject changed to "Equals and Hashcode question in new release?" by Brian Nicoloff
Brian Nicoloff  
View profile  
 More options Oct 1 2008, 1:56 pm
From: "Brian Nicoloff" <nicol...@sbcglobal.net>
Date: Wed, 1 Oct 2008 12:56:34 -0500
Local: Wed, Oct 1 2008 1:56 pm
Subject: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Billy,

Thanks for the new release.  Looks like there are some nice features in
there.  However, I had written some of my own unit tests on for the previous
version and found that 4 of the tests broke with the new release.  It seems
that when I have two transient objects with the domain signature properties
of FirstName and LastName, if I set one objects properties to FName1 and
LName1 and a different objects properties to FName2 and LName2, the result
is coming back as true when they are compared.  If I change the different
object property values to something like diffname and difflastname the
comparison returns false as expected. Am I writing this test wrong or is
this the expected behavior?  Here is the Unit Test code that I am using that
has brought about the issue. If you change the _diffObj and the
_diffObjWithId FirstName and LastName properties the tests will run fine.
Thanks again for this great architecture.

Brian

using NUnit.Framework;
using SharpArch.Core;
using SharpArch.Core.PersistenceSupport;

namespace Tests.SharpArch.Core.PersistenceSupport
{
  [TestFixture]
  [Category("Unit")]
  public class MyPersistentObjectTests
  {
    private MockPersistentDomainObjectWithDefaultId _obj;
    private MockPersistentDomainObjectWithDefaultId _sameObj;
    private MockPersistentDomainObjectWithDefaultId _diffObj;
    private MockPersistentDomainObjectWithSetId _objWithId;
    private MockPersistentDomainObjectWithSetId _sameObjWithId;
    private MockPersistentDomainObjectWithSetId _diffObjWithId;

    [SetUp]
    public void Setup()
    {
      _obj = new MockPersistentDomainObjectWithDefaultId
               {
                 FirstName = "FName1",
                 LastName = "LName1",
                 Email = "testus...@mail.com"
               };
      _sameObj = new MockPersistentDomainObjectWithDefaultId
                   {
                     FirstName = "FName1",
                     LastName = "LName1",
                     Email = "testus...@mail.com"
                   };
      _diffObj = new MockPersistentDomainObjectWithDefaultId
                   {
                     FirstName = "FName2",
                     LastName = "LName2",
                     Email = "testuse...@mail.com"
                   };

      _objWithId = new MockPersistentDomainObjectWithSetId
                     {
                       FirstName = "FName1",
                       LastName = "LName1",
                       Email = "testus...@mail.com"
                     };
      _sameObjWithId = new MockPersistentDomainObjectWithSetId
                         {
                           FirstName = "FName1",
                           LastName = "LName1",
                           Email = "testus...@mail.com"
                         };
      _diffObjWithId = new MockPersistentDomainObjectWithSetId
                         {
                           FirstName = "FName2",
                           LastName = "LName2",
                           Email = "testuse...@mail.com"
                         };
    }

    [TearDown]
    public void Teardown()
    {
      _obj = null;
      _sameObj = null;
      _diffObj = null;
    }

    [Test]
    [Category("Unit")]
    public void
DoesDefaultPersistentObjectEqualsOverrideWorkWhenNoIdIsAssigned()
    {
      Assert.That(_obj.Equals(_sameObj));
      Assert.That(!_obj.Equals(_diffObj));
      Assert.That(!_obj.Equals(new
MockPersistentDomainObjectWithDefaultId()));
    }

    [Test]
    [Category("Unit")]
    public void
DoEqualDefaultPersistentObjectsWithNoIdsGenerateSameHashCodes()
    {
      Assert.That(_obj.GetHashCode().Equals(_sameObj.GetHashCode()));
    }

    [Test]
    [Category("Unit")]
    public void
DoEqualDefaultPersistentObjectsWithMatchingIdsGenerateDifferentHashCodes()
    {
      Assert.That(!_obj.GetHashCode().Equals(_diffObj.GetHashCode()));
    }

    [Test]
    [Category("Unit")]
    public void
DoDefaultPersistentObjectEqualsOverrideWorkWhenIdIsAssigned()
    {
      _obj.SetAssignedIdTo(1);
      _diffObj.SetAssignedIdTo(1);
      Assert.That(_obj.Equals(_diffObj));
    }

    [Test]
    [Category("Unit")]
    public void DoesPersistentObjectEqualsOverrideWorkWhenNoIdIsAssigned()
    {
      Assert.That(_objWithId.Equals(_sameObjWithId));
      Assert.That(!_objWithId.Equals(_diffObjWithId));
      Assert.That(!_objWithId.Equals(new
MockPersistentDomainObjectWithSetId()));
    }

    [Test]
    [Category("Unit")]
    public void DoEqualPersistentObjectsWithNoIdsGenerateSameHashCodes()
    {

Assert.That(_objWithId.GetHashCode().Equals(_sameObjWithId.GetHashCode()));

    }

    [Test]
    [Category("Unit")]
    public void
DoEqualPersistentObjectsWithMatchingIdsGenerateDifferentHashCodes()
    {

Assert.That(!_objWithId.GetHashCode().Equals(_diffObjWithId.GetHashCode())) ;
    }

    [Test]
    [Category("Unit")]
    public void DoPersistentObjectEqualsOverrideWorkWhenIdIsAssigned()
    {
      _objWithId.SetAssignedIdTo("1");
      _diffObjWithId.SetAssignedIdTo("1");
      Assert.That(_objWithId.Equals(_diffObjWithId));
    }
  }

  public class MockPersistentDomainObjectWithSetId :
MockPersistentDomainObjectBase<string>, IHasAssignedId<string>
  {
    public void SetAssignedIdTo(string assignedId)
    {
      ID = assignedId;
    }
  }

  public class MockPersistentDomainObjectWithDefaultId :
MockPersistentDomainObjectBase, IHasAssignedId<int>
  {
    public void SetAssignedIdTo(int assignedId)
    {
      ID = assignedId;
    }
  }

  public class MockPersistentDomainObjectBase :
MockPersistentDomainObjectBase<int> { }

  public class MockPersistentDomainObjectBase<T> :
PersistentObjectWithTypedId<T>
  {
    [DomainSignature]
    public string FirstName { get; set; }

    [DomainSignature]
    public string LastName { get; set; }

    public string Email { get; set; }
  }


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Luis Abreu  
View profile  
 More options Oct 1 2008, 2:07 pm
From: "Luis Abreu" <lab...@gmail.com>
Date: Wed, 1 Oct 2008 19:07:25 +0100
Local: Wed, Oct 1 2008 2:07 pm
Subject: RE: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Hello.

If I'm not mistaken, the only change that has happened is that now you'll
get into domain business signature comparison only if both objects are
transient or not (simultaneously)...

--
Luis Abreu


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Brian Nicoloff  
View profile  
 More options Oct 1 2008, 2:21 pm
From: "Brian Nicoloff" <nicol...@sbcglobal.net>
Date: Wed, 1 Oct 2008 13:21:52 -0500
Local: Wed, Oct 1 2008 2:21 pm
Subject: RE: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
That's what I thought too, but these test cases are showing otherwise.  They
ran fine prior to this release.  It seems that the hashcode is returning the
same value for the two objects when the domain signatures are off by 1
character. For instance when the FirstName property value is set to FName1
on one object and the property is set to FName2 on the other object, the
hashcode is returning the same value.


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Luis Abreu  
View profile  
 More options Oct 1 2008, 4:37 pm
From: "Luis Abreu" <lab...@gmail.com>
Date: Wed, 1 Oct 2008 21:37:13 +0100
Local: Wed, Oct 1 2008 4:37 pm
Subject: RE: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Well, I can see you get a false positive by exchanging values on properties
of the same type. Billy, what do you think about this example:

private class ObjectWithIntId2 : PersistentObject {
            [DomainSignature]
            public string Name { get; set; }
            [DomainSignature]
            public string Address { et; set; }

}

Now, the test:

[Test]
public void ShouldBeDifferent()
{
   var obj1 = new ObjectWithIntId2 {Name = "A", Address = "B"};
   var obj2 = new ObjectWithIntId2 { Name = "B", Address = "A" };
   Assert.That(obj1, Is.Not.EqualTo(obj2));

}

Ok, i think that we need to run equals on the properties instead of using
the hashcode. What do you guys think?

--
Luis Abreu


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Brian Nicoloff  
View profile  
 More options Oct 1 2008, 5:09 pm
From: "Brian Nicoloff" <nicol...@sbcglobal.net>
Date: Wed, 1 Oct 2008 16:09:31 -0500
Local: Wed, Oct 1 2008 5:09 pm
Subject: RE: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
I agree with that.  I am by no means an expert on how the hash code
determines equality, but with your example and the previous one that I
uncovered, it seems that there is definitely a problem when comparing 2
objects based on their [DomainSignature] properties.

Brian


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Luis Abreu  
View profile  
 More options Oct 1 2008, 5:29 pm
From: "Luis Abreu" <lab...@gmail.com>
Date: Wed, 1 Oct 2008 22:29:38 +0100
Local: Wed, Oct 1 2008 5:29 pm
Subject: RE: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Yes, but I'm not sure your case is similar to mine. After all, you have 2
different values while I have the same values swapped (which is why I'm
getting the wrong result on my test)....

--
Luis Abreu

...

read more »


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Brian Nicoloff  
View profile  
 More options Oct 1 2008, 5:47 pm
From: "Brian Nicoloff" <nicol...@sbcglobal.net>
Date: Wed, 1 Oct 2008 16:47:53 -0500
Local: Wed, Oct 1 2008 5:47 pm
Subject: RE: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
It could be two separate problems I guess.  Tracing through my test code
points to the same issue with the hash code that you suggested though.  Both
property values are returning the same hash code when they are similar.  It
seems that if the code checked for property equality rather than hash code
it will work.

...

read more »


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Luis Abreu  
View profile  
 More options Oct 1 2008, 5:50 pm
From: "Luis Abreu" <lab...@gmail.com>
Date: Wed, 1 Oct 2008 22:50:55 +0100
Local: Wed, Oct 1 2008 5:50 pm
Subject: RE: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Hum...that is interesting...I mean, in my case, it was obvious I'd get the
same hash because I?ve just exchanged the properties' values, but in yours
you had different values (ie, you f1/l1 and then f2/l2 - or something along
these lines). I expected that the hashcode for these would always be
different, but again, I might be wrong.

--
Luis Abreu

...

read more »


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Brian Nicoloff  
View profile  
 More options Oct 1 2008, 6:11 pm
From: "Brian Nicoloff" <nicol...@sbcglobal.net>
Date: Wed, 1 Oct 2008 17:11:21 -0500
Local: Wed, Oct 1 2008 6:11 pm
Subject: RE: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Yes, that was my assumption of the way that the hash code worked as well.
But, running the test through the debugger brings up the same HashCode in
the GetDomainObjectSignature() method for the following objects where
FirstName and LastName are the combined DomainSignature for the class.

_sameObj = new transientObject
                   {
                     FirstName = "FName1",
                     LastName = "LName1",
                     Email = "testus...@mail.com"
                   };

_diffObj = new transientObject
                   {
                     FirstName = "FName2",
                     LastName = "LName2",
                     Email = "testuse...@mail.com"
                   };

------
Brian

...

read more »


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Luis Abreu  
View profile  
 More options Oct 2 2008, 5:26 am
From: "Luis Abreu" <lab...@gmail.com>
Date: Thu, 2 Oct 2008 10:26:37 +0100
Local: Thurs, Oct 2 2008 5:26 am
Subject: Re: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
incredible...I've just run some powershell tests and yes, you're
correct. Interestingly, each string has its own integer value but when
youo combine them with ^operator you get the same result...

so, we do need some way to corretly implement hascode...anyone good with math?

...

read more »


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Martin Hornagold  
View profile  
 More options Oct 2 2008, 5:43 am
From: "Martin Hornagold" <Martin.Hornag...@marstangroup.com>
Date: Thu, 2 Oct 2008 10:43:09 +0100
Local: Thurs, Oct 2 2008 5:43 am
Subject: RE: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Hi guys and Billy,

Just did a quick hunt and found a useful article on the same problem
documented for Java:

http://mindprod.com/jgloss/hashcode.html

Relevant quote from the article:

The nasty properties of XOR are:
It treats identical pairs of components as if they were not there.
It ignores order. A ^ B is the same a B ^ A. If order matters, you want
some sort of checksum/digest such as Adlerian. XOR would not be suitable
to compute the hashCode for a List which depends on the order of the
elements as part of its identity.
If the values to be combined are only 8 bits wide, there will be
effectively only 8 bits in the xored result. In contrast, multiplying by
a prime and adding would scramble the entire 32 bits of the result,
giving a much broader range of possible values, hence greater chance
that each hashcode will unique to a single Object. In other words, it
tends to expand the range of the digest into the widest possible band
(32 bits).

There are some examples of implementation.

Hope it helps

Martin

...

read more »


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Luis Abreu  
View profile  
 More options Oct 2 2008, 6:10 am
From: "Luis Abreu" <lab...@gmail.com>
Date: Thu, 2 Oct 2008 11:10:08 +0100
Local: Thurs, Oct 2 2008 6:10 am
Subject: Re: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Hello guys.

I guess that the problem is that we're thinking about the GetHashcode
method incorrectly. Ok, if 2 objects are equal, the hashcode must be
equal, but if two objects are different, there's nothing out there
that says that they must return a different hashcode! So, the problem
here is that we're using the hascode for equality when we shouldn't be
doing that. Even with a fancy algorythm, there's always the chance of
having 2 "different" objects returning the same hashcode.

So, I'd really prefer to add a method that compares properties instead
of relying in hashcode. For instance, adding a method like this:

protected bool DoObjectsHaveSomeBusinessSignature(DomainSignatureComparable to)
        {
            Boolean hasDomainSignatureSpecified = false;
            foreach (PropertyInfo property in GetType().GetProperties())
            {
                if (IsPartOfDomainSignature(property))
                {
                    hasDomainSignatureSpecified = true;
                    object value = property.GetValue(this, null);
                    object anotherValue = property.GetValue(to, null);
                    if( !value.Equals(anotherValue) )
                    {
                        return false;
                    }
                }
            }
            return true & hasDomainSignatureSpecified;
        }

And then I'd change the DomainSignatureComparable Equals to:

public override bool Equals(object obj) {
            DomainSignatureComparable compareTo = obj as
DomainSignatureComparable;

            return compareTo != null &&
                DoObjectsHaveSomeBusinessSignature(compareTo);
        }

and, of course, the Equals method oe PersistentObject to:

public override bool Equals(object obj) {
            PersistentObjectWithTypedId<IdT> compareTo = obj as
PersistentObjectWithTypedId<IdT>;

            return compareTo != null &&
                   (HasSameNonDefaultIdAs(compareTo) ||
                    // Since the IDs aren't the same, both of them
must be transient to
                    // compare business value signatures.  If one is
transient and the other is
                    // a persisted entity, then they cannot be the same object.
                    (((IsTransient()) && compareTo.IsTransient()) &&
                     DoObjectsHaveSomeBusinessSignature(compareTo)));
        }

Ok, this breaks the domainscignaturecomparable tests (only!). no doubt
about it. However. i believe that this is a good thing because I'm not
sure about these tests. For instance, the
CanCompareDomainObjectsWithOnlySomePropertiesBeingPartOfDomainSignature
looks like this:

public void CanCompareDomainObjectsWithOnlySomePropertiesBeingPartOfDomainSignature()
{
            ObjectWithOneDomainSignatureProperty object1 = new
ObjectWithOneDomainSignatureProperty();
            ObjectWithOneDomainSignatureProperty object2 = new
ObjectWithOneDomainSignatureProperty();
            Assert.That(object1, Is.Not.EqualTo(object2));

            object1.Age = 13;
            object2.Age = 13;
            // Name property isn't included in comparison
            object1.Name = "Foo";
            object2.Name = "Bar";
            Assert.That(object1, Is.EqualTo(object2));

            object1.Age = 14;
            Assert.That(object1, Is.Not.EqualTo(object2));
        }

Now, why do we have the first assertion? I mean,
DomainSignatureComparable does not have the concept of transitory
objects. So, I think that the 1st Assert is wrong. Here's how I expect
this class to behave:

1. if there isn't any property anotated with the domainsignature
attribute, then I expect it to return false (always). I assume this
because in this case equality is synonim of having the same values
applied to predefined properties. Ok, there's one case where I think
some debate is in order: what if we have two references to the same
object of a type that doesn't has any property used in the domain
signature? Ideas? Btw, it could be useful to optimize the code by
using Object.ReferenceEquals in my previous code suggestion. if it
returns true, then there's no need of going throught reflection,
right?
2. if the class does have domain signature properties, then the
equality should be true if all those properties have the same value.
Now, if you look at the previous test, that is true: the age property
is part of the signature and since the class doesn't has the concept
of transient (delegate to the persistenobjectXXX class), then that
assert shouldn't hold. ie, two new instances will get the same value
for their ID, which means that they should be equal. Note that I'm
talking about the domainsignaturecomparable class, not anout the
persistenobjectXXX class. If the DomainSignatureComparable class had
the notion of transient object, then I would expect that assert to
hold...

so, what do you think?

On Thu, Oct 2, 2008 at 10:43 AM, Martin Hornagold

...

read more »


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Luis Abreu  
View profile  
 More options Oct 2 2008, 6:48 am
From: "Luis Abreu" <lab...@gmail.com>
Date: Thu, 2 Oct 2008 11:48:31 +0100
Local: Thurs, Oct 2 2008 6:48 am
Subject: Re: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
small correction to the previous snippets:

public abstract class DomainSignatureComparable {
        public override bool Equals(object obj) {
            var compareTo = obj as DomainSignatureComparable;

            if (ReferenceEquals(this, compareTo)) return true;
            return compareTo != null &&
                DoObjectsHaveSomeBusinessSignature(compareTo);
        }

        /// <summary>
        /// Used to compare two objects via <see cref="Equals"/>;
although it's necessary for
        /// NHibernate's use, this may also be useful for business
logic purposes.
        /// </summary>
        public override int GetHashCode() {
            // Since it's possible for two objects to return the same
domain signature,
            // even if they're of two different types, it's important
to include the object's
            // type in the domain signature
            return GetType().GetHashCode() ^ GetDomainObjectSignature();
        }

        /// <summary>
        /// The method GetDomainObjectSignature should ONLY return the
"business value
        /// signature" of the object and not the ID, which is handled
by <see cref="PersistentObject" />.
        ///
        /// If you choose NOT to override this method, then you should
decorate the appropriate
        /// property(s) with [DomainSignature] and they will be
compared automatically.  Using the
        /// [DomainSignature] attribute is the preferred method.
        ///
        /// Alternatively, if you override this method, the general
structure of the overridden method
        /// should be as follows:
        ///
        /// return SomeProperty.GetHashCode() ^ SomeOtherProperty.GetHashCode();
        ///
        /// </summary>
        protected virtual int GetDomainObjectSignature() {
            var domainObjectSignature = 0;

            foreach (var property in GetType().GetProperties()) {
                if (!IsPartOfDomainSignature(property))
                {
                    continue;
                }
                var value = property.GetValue(this, null);

                if (value != null) {
                    domainObjectSignature = domainObjectSignature ^
value.GetHashCode();
                }
            }

            // If no properties were flagged as being part of the
domain signature of the object,
            // then simply return the hashcode of the base object as
the domain signature.  This
            // behaves as you would normally expect Equals to behave
when comparing two objects.
            return domainObjectSignature == 0 ? base.GetHashCode() :
domainObjectSignature;
        }

        protected bool
DoObjectsHaveSomeBusinessSignature(DomainSignatureComparable to) {
            var hasDomainSignatureSpecified = false;
            foreach (var property in GetType().GetProperties()) {
                if (!IsPartOfDomainSignature(property))
                {
                    continue;
                }
                hasDomainSignatureSpecified = true;
                var value = property.GetValue(this, null);
                var anotherValue = property.GetValue(to, null);
                if(ReferenceEquals(value, anotherValue) ) return true;
                if( value == null || anotherValue == null) return false;
                if (!value.Equals(anotherValue)) {
                    return false;
                }
            }
            return true & hasDomainSignatureSpecified;
        }

        private static Boolean IsPartOfDomainSignature(PropertyInfo property) {
            return
property.GetCustomAttributes(typeof(DomainSignatureAttribute),
true).Length > 0;
        }
    }

...

read more »


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Brian Nicoloff  
View profile  
 More options Oct 2 2008, 11:58 am
From: "Brian Nicoloff" <nicol...@sbcglobal.net>
Date: Thu, 2 Oct 2008 10:58:08 -0500
Local: Thurs, Oct 2 2008 11:58 am
Subject: RE: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Luis,
I agree with both of your statements below regarding the
DomainSignatureComparable behavior.  I think that the Object.ReferenceEquals
handles the situation where we have two references to the same object of a
type that doesn't have any property used in the domain.  My only change to
the code that you provided would be to possibly make the hash code a little
more unique by changing the GetDomainObjectSignature method to the
following:

 protected virtual int GetDomainObjectSignature()
 {
    var domainObjectSignature = 0;
    var strValues = new StringBuilder();

    foreach (var property in GetType().GetProperties())
    {
      if (!IsPartOfDomainSignature(property))
      {
         continue;
      }
      var value = property.GetValue(this, null);

      if (value != null)
      {
         strValues.Append(value.ToString());
      }
    }

    domainObjectSignature = strValues.ToString().GetHashCode();

    // If no properties were flagged as being part of the domain signature
of the object,
    // then simply return the hashcode of the base object as the domain
signature.  This
    // behaves as you would normally expect Equals to behave when comparing
two objects.
    return strValues.ToString().GetHashCode == 0 ? base.GetHashCode() :
domainObjectSignature;
 }

By appending the string values to a single hash code it seems to return a
unique code in the test case that I had previously had problems with.  I
still agree that we should not rely on the hash code to determine property
equality though.  

Brian

...

read more »


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Luis Abreu  
View profile  
 More options Oct 2 2008, 3:55 pm
From: "Luis Abreu" <lab...@gmail.com>
Date: Thu, 2 Oct 2008 20:55:32 +0100
Local: Thurs, Oct 2 2008 3:55 pm
Subject: RE: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Hum...well, calculating a hashcode is...you know, hard:)

Most of the implementations I've seen are really happy delegating to its
inner properties, so I'd leave it like that...

Anyways, we must wait for Billy to see what he thinks about the ideas we've
presented here.

--
Luis Abreu

...

read more »


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Brian Nicoloff  
View profile  
 More options Oct 2 2008, 5:39 pm
From: "Brian Nicoloff" <nicol...@sbcglobal.net>
Date: Thu, 2 Oct 2008 16:39:40 -0500
Local: Thurs, Oct 2 2008 5:39 pm
Subject: RE: Equals and Hashcode question in new release?
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Sounds good.  Thanks for your help.

...

read more »


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Discussion subject changed to "Version 0.8.0 with MVC Preview 5, NH 2.0 and Ninject 1.0 now available!" by Simone Busoli
Simone Busoli  
View profile  
 More options Oct 4 2008, 6:40 pm
From: "Simone Busoli" <simone.bus...@gmail.com>
Date: Sun, 5 Oct 2008 00:40:51 +0200
Local: Sat, Oct 4 2008 6:40 pm
Subject: Re: Version 0.8.0 with MVC Preview 5, NH 2.0 and Ninject 1.0 now available!
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author

Billy, is the project going to be a one man show forever? Just to know if I,
or anyone, should bother discussing changes, fixes or improvements.


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Billy  
View profile  
 More options Oct 5 2008, 1:46 am
From: Billy <googlegro...@emccafferty.com>
Date: Sat, 4 Oct 2008 22:46:07 -0700 (PDT)
Local: Sun, Oct 5 2008 1:46 am
Subject: Re: Version 0.8.0 with MVC Preview 5, NH 2.0 and Ninject 1.0 now available!
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
No!  In fact, the changes that I just checked in (which I'll be making
0.8.1) include most of the patch which you've provided (and probably
thought that I did not notice)...so thank you Simone for the
contribution!!  Additionally, I'd like to sincerely thank Brian
Nicoloff (especially for the comprehensive unit tests), Luis Abreu,
and Martin Hornagold for this discussion which exposed a serious flaw
in the existing logic and provided terrific discussion for the
applicability of Equals and GetHashCode, and the logic therein.  The
fact of the matter is, this architecture, and current release, is a
true reflection of everyone who has participated within these
discussions.  I only wish to keep the check in/out of the core code
base between now and 1.0 to myself and Frank Laub, who has been
instrumental in the formalization of this architecture, for the sole
motivation that I wish to consider the feedback from all developers
and incorporate the guidance which is most in line with my own
(arguably selfish) goals for where I want this architecture to be and
how I want it to be used.  My aspiration is that S#arp Architecture
will become the "Ruby on Rails" foundation for ASP.NET MVC; I feel
that we will get it there with all of your input and assistance.

The most recent check-in (which will be part of 0.8.1) includes the
following assumptions with respect to Equals and GetHashCode:
* Equals and GetHashCode should behave identically (this is up for
argument from a theoretical standpoint but an assumption for #arch).
Similar to the guidance provided within
http://www.hibernate.org/hib_docs/nhibernate/html/persistent-classes....
, the code with #arch leverages the GetHashCode method to enable
checks for equality; #arch is just a bit more explicit about the
assumed overlap;
* If two objects inherit from DomainSignatureComparable, and are
compared, then it is assumed that the comparison between the two is
solely dependent on the properties marked with the attribute
[DomainSignature].  If no properties are decorated with the
DomainSignature attribute, then the comparison between the two objects
is treated as .NET natively compares object equality:  by memory
reference with the ReferenceEquals method;
* Two DomainSignatureComparable objects which point to the same memory
location (i.e., are the same object in memory) are always equal;
* Two PersistentObject/PersistentObjectWithTypedId objects which have
the same ID are always equal;
* If two PersistentObject are compared and one of them is transient
while the other is persistent, they will always be different from a
standpoint from equality;
* Any PersistentObject properties which are not decorated with the
DomainSignature attribute will not be included in the comparison of
two PersistentObject object; consequently, ONLY the properties
decorated with the DomainSinature attribute will have an impact on
comparison.

As always, your continued feedback is most appreciated.

Billy

On Oct 4, 4:40 pm, "Simone Busoli" <simone.bus...@gmail.com> wrote:


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Luis Abreu  
View profile  
 More options Oct 5 2008, 1:18 pm
From: "Luis Abreu" <lab...@gmail.com>
Date: Sun, 5 Oct 2008 18:18:36 +0100
Local: Sun, Oct 5 2008 1:18 pm
Subject: RE: Version 0.8.0 with MVC Preview 5, NH 2.0 and Ninject 1.0 now available!
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Hello guys,

Just one question (probably didn't get this right):

> * Two PersistentObject/PersistentObjectWithTypedId objects which have
> the same ID are always equal;

So, are you using the db key for checking equality between objects? Are we
dismissing the attributes annotated with the DomainSignatureAttribute from
this comparison? If so, is this wise?

Luis


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Simone Busoli  
View profile  
 More options Oct 5 2008, 1:51 pm
From: "Simone Busoli" <simone.bus...@gmail.com>
Date: Sun, 5 Oct 2008 19:51:59 +0200
Local: Sun, Oct 5 2008 1:51 pm
Subject: Re: Version 0.8.0 with MVC Preview 5, NH 2.0 and Ninject 1.0 now available!
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author

If two objects are persistent, doesn't it make sense to consider them equal
if they have the same ID? The ID is not necessarily the ID in the DB.


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Luis Abreu  
View profile  
 More options Oct 5 2008, 3:12 pm
From: "Luis Abreu" <lab...@gmail.com>
Date: Sun, 5 Oct 2008 20:12:41 +0100
Local: Sun, Oct 5 2008 3:12 pm
Subject: RE: Version 0.8.0 with MVC Preview 5, NH 2.0 and Ninject 1.0 now available!
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author

Probably, but the question is: does it work in all the scenarios?

--
Luis Abreu

From: sharp-architecture@googlegroups.com
[mailto:sharp-architecture@googlegroups.com] On Behalf Of Simone Busoli
Sent: domingo, 5 de Outubro de 2008 18:52
To: sharp-architecture@googlegroups.com
Subject: Re: Version 0.8.0 with MVC Preview 5, NH 2.0 and Ninject 1.0 now
available!

If two objects are persistent, doesn't it make sense to consider them equal
if they have the same ID? The ID is not necessarily the ID in the DB.

On Sun, Oct 5, 2008 at 7:18 PM, Luis Abreu <lab...@gmail.com> wrote:

Hello guys,

Just one question (probably didn't get this right):

> * Two PersistentObject/PersistentObjectWithTypedId objects which have
> the same ID are always equal;

So, are you using the db key for checking equality between objects? Are we
dismissing the attributes annotated with the DomainSignatureAttribute from
this comparison? If so, is this wise?

Luis

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.7.5/1703 - Release Date: 05-10-2008
09:20


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Billy  
View profile  
 More options Oct 5 2008, 7:11 pm
From: Billy <googlegro...@emccafferty.com>
Date: Sun, 5 Oct 2008 16:11:34 -0700 (PDT)
Local: Sun, Oct 5 2008 7:11 pm
Subject: Re: Version 0.8.0 with MVC Preview 5, NH 2.0 and Ninject 1.0 now available!
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
Assuming equal ID (and type) implies object equality is the approach
I've been using for a few years and I haven't run into an outside case
yet; not that that means that it's inappropriate in some situations,
but I have yet to run into them.  My thoughts on this is that if you
legally change your name from Luis to George, that you're still the
same person that you were before but with a different property value.
Your ID in this instance would be an assigned ID being your social
security number (or possibly some auto-generated one from the DB).

Billy

On Oct 5, 1:12 pm, "Luis Abreu" <lab...@gmail.com> wrote:


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Simone Busoli  
View profile  
 More options Oct 5 2008, 7:20 pm
From: "Simone Busoli" <simone.bus...@gmail.com>
Date: Mon, 6 Oct 2008 01:20:47 +0200
Local: Sun, Oct 5 2008 7:20 pm
Subject: Re: Version 0.8.0 with MVC Preview 5, NH 2.0 and Ninject 1.0 now available!
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author

This is definitely the way to go with persistent objects, at least according
to DDD, where objects with an identity are called entities. Their identity
is not regulated by the equality of their attributes (these are called value
objects), but by a higher level concept, according to the domain in which
your objects live.


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Luis Abreu  
View profile  
 More options Oct 6 2008, 5:45 am
From: "Luis Abreu" <lab...@gmail.com>
Date: Mon, 6 Oct 2008 10:45:12 +0100
Local: Mon, Oct 6 2008 5:45 am
Subject: Re: Version 0.8.0 with MVC Preview 5, NH 2.0 and Ninject 1.0 now available!
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
regarding the name change, that's where the domain business signature
enters. You wouldn't promote Name to a business signature, right?

I'll have to think a little more about that to see if I agree. I mean,
it makes sense, but you'll also need to garantee that nobody changes
the value of the ID after its set....need to think a little more about
it....

--
Regards,
Luis Abreu

    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Messages 1 - 25 of 55   Newer >
« Back to Discussions « Newer topic     Older topic »

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google