Criteria objects & a lot of beers :)

Boris posted on Tuesday, March 24, 2009

Rocky,

I clearly remember from your last books that:

---
At a minimum, the criteria object must specify the type
of object you are trying to create, retrieve, or delete
---

I also know that criteria can be created in one of three ways
(page 81 in Expert C# 2008 Business Objects)

...So this what I've been pushing for..create criteria,
that will convey to the App. Server information about the type (at a minimum) of the BO.

Well, what is the difference then, between the following two calls:

    public static Project GetProject(Guid id)
    {
      return DataPortal.Fetch<Project>(new SingleCriteria<Project, Guid>(id));
    }

    // and

    public static Project GetProject(Guid id)
    {
      return DataPortal.Fetch<Project>(Guid id);
    }


Thanks,

~ Boris

Boris replied on Tuesday, March 24, 2009

Of course, to be absolutely precise the second call is:

    public static Project GetProject(Guid id)
    {
      return DataPortal.Fetch<Project>(id);
    }

   And the
private void DataPortal_Fetch(SingleCriteria<Project, Guid> criteria) {...}
   changes to
private void DataPortal_Fetch(Guid id) {...}

RockfordLhotka replied on Wednesday, March 25, 2009

The first one is correct, the other is not :)

The data portal is designed to carry a criteria object over the wire. It is absolutely not guaranteed that arbitrary primitive values will work, and an Int32 type specifically will not work (because the data portal uses that type internally).

If I didn't care about backward compatibility I'd allow arbitrary values, and someday I may make that change (which would involve eliminating the non-generic data portal methods like Create() and Fetch()).

But unless I make that breaking change, the data portal is only designed to work with criteria objects as parameters, not arbitrary primitive values.

Of course a Guid is not a primitive, and so it is probably pretty safe :)

Boris replied on Wednesday, March 25, 2009

Rocky,

Thank you for the quick responce!
I confirmed what you're saying and that makes sense to me...

I cannot say I completely understand how the DataPortal is using the Int32 internally, and why is the call obj.CallMethod("DataPortal_Fetch") needed in SimpleDataPortal.

        // tell the business object to fetch its data
        if (criteria is int)
          obj.CallMethod("DataPortal_Fetch");
        else
          obj.CallMethod("DataPortal_Fetch", criteria);

I just didn't have the time to expolre that yet, but I think this where you mean backward compatibility thing...

Thank you!

JoeFallon1 replied on Wednesday, March 25, 2009

This is discussed in the book in Chapter 15 for the SimpleDataPortal.

Rocky needed a "magic" value to determine which path to take and arbitrarily decide to use an int because the DataPortal is designed to accept a Criteria Object which is NOT a primitive type.

But there are overloads for Fetch that do not require *any* criteria at all and no parameter is not the same thing as Nothing.

So Rocky assigns it a magic value to indicate that no parameter was passed at all.

Joe

RockfordLhotka replied on Wednesday, March 25, 2009

The 'magic value' idea is not ideal, but it is with good reason.

The alternative is to use a more complex message container to transfer the
parameter(s). That would have broken backward compatibility at the time (and
would now). Perhaps more importantly, it would have increased the size of
the fetch request on the wire, and I wanted to keep that as compact as
possible.

Rocky