GetMany Method/SP?

Oct 16, 2007 at 6:51 PM
Is there a way to create a GetMany stored procedure and repository which would take in some sort of criteria object with parameters relating to each column in the table? So that I can get a list of Entities based on a search criteria that isn't a primary or foreign key?
Oct 16, 2007 at 7:47 PM

MattBell wrote:
Is there a way to create a GetMany stored procedure and repository which would take in some sort of criteria object with parameters relating to each column in the table? So that I can get a list of Entities based on a search criteria that isn't a primary or foreign key?


If I understand your question correctly, then no, there's nothing in the code generation that will do what you want. You can, however, write the appropriate selection factory and repository method by hand and add it to the generated repository.
Oct 16, 2007 at 9:27 PM
I created a stored procedure which took in all of the columns of the table and returns a result set based on comparison with those parameters.
I then ran the Create data repository classes from business entities recipie and mapped my business entity to the stored procedure I wrote.

What's interesting is that in how it code gens it is to create a method declaration with all of the properties of the business object, then it maps it to a new object which is a mirror of that entity, and then maps that new object to the sql parameters. Then has another mapper which takes the resultant datareader and maps it back to the business entity.

Perhaps the factory could be modified to create a GetMany method which cuts out the first step and simply takes in a business entity as it's parameter and passes it to the Find method?

Or is this not the place to make a request like that? I'm new to this sort of thing.
Developer
Oct 17, 2007 at 7:10 AM
You have a point there, MattBell.

It seems a bit odd when you have a bounch of parameters on input to a Repository method, that each parameter first is mapped to a Criteria Business entity after you have written them to the method. I myself have done as you and written my own Criteria Business Entity and rewritten the method to expect my Criteria instead of a bunch of parameteres. There should be a selection if you want your parameters to be mapped to a criteria business entity in the wizard.

Benny
Oct 18, 2007 at 5:44 AM

BennyXNO wrote:
You have a point there, MattBell.

It seems a bit odd when you have a bounch of parameters on input to a Repository method, that each parameter first is mapped to a Criteria Business entity after you have written them to the method. I myself have done as you and written my own Criteria Business Entity and rewritten the method to expect my Criteria instead of a bunch of parameteres. There should be a selection if you want your parameters to be mapped to a criteria business entity in the wizard.

Benny


Believe it or not, there was a reason for it to be implemented the way it was. ;-)

Basically, we needed a solution that would work with arbitrary sprocs. Not every sproc will take all and only the fields in the entity; in fact most of them don't. Even if it did, in many cases you only want to specify some of the fields in the entity, but the entity logic won't let you do that. For example, a PO entity won't let you initialize one without a customer #, but all you want is to search for ones which are more than $500.

We could have built some sort of criteria object generation in, but rather than force folks to use yet another object (after all the complaints about the number of classes we generate) we felt the scalar parameters were easier to use and made more sense.

The identity objects were introduced to simplify the code generation. They're just there to package up all the parameters so that we can have a single generic interface with only one type parameter. They don't actually do anything but transfer the data.

Anyway, just wanted to add a little history into the conversation.

-Chris
Developer
Oct 18, 2007 at 5:44 PM
Nice little story, Chris.

And you didnt do anything wrong in your design. But when methods get more then say 4 scalar input parameters they get unmanagable and difficult to change. If you introduce a Criteria Business Entity, okei, you make the class diagram more messy, but the design gets easier to read.

The Criteria Business Entity has some ground rules it should follow:
- Must have one default constructor with no arguments.
- May have one public constructor with sets all members.
- It should only have members, no getters/setters.
- It should not have any business logic attached to it.
- It acts only as a container to transfer criteria's information.

So you identity objects are nice little things using the Criteria Business Entity, And it had been perfect if your GetMany procedure had used the Criteria Business Entity also.

The nice little gift you are getting from using the Criteria Business Entity is that its get less complex to change the method if your suddently should need a new member in the Criteria. Then you only need to change things in the commandbuilder, the Criteria Entity and in the outer method where you set the members.


Benny