Here's a real good one. I'm trying to build a way for administrators to group users by many different properties. We are calling them "Positions", but it's a little more involved than just their job title.

It is based on the "Smart Playlist" style of iTunes where you can choose the EntityType, select the field that you want to filter, select a "like, in, not in, equals, not equals" dropdownlist, then enter the filter parameters.

I have the basic table layout set up to store these, but I don't know how I would set this up in LLBLGenPro's Self Servicing Generated Code. Here's my table layout:

Position ID - PK, Identity Name (and some other fields)

Entity - lists the entity types that can be filtered ID - PK, Identity Name - e.g., Location LLBLName - Name of the entity, such as LocationEntity

EntityFields - lists the fields in an entity that can be filtered ID - PK, Identity EntityID - FK to Entity LLBLFieldName - FieldIndex of the Entity

PositionParams ID - PK, Identity PositionID - FK to Position EntityFieldID - FK to EntityFields EnumFilterType - FK to FilterType ParamValue - value from the textbox

How would I be able to define a query (TypedListDAO) that would return the result set that I want? Has anyone any ideas on how I would be able to do this?

If this is not a good approach, I would like to get some constructive criticism on my design

Reflection is the first thing that comes to my mind.

Using the Entity and Fields names.

To me the first thing that comes to mind is a dynamic query, but..

Just for clarification is a position simply a predefined query? How will positions be defined? One time by an admin? Or will there be a UI?

Will this only return one type of entity?

If so you could just add the predicates when you fetch a collection.

-Or-

Is it able to return just specific fields from any entity?

This may require your query system to have knowledge of the relationships between entities. However this you could probably do with a dynamic list. See Generated code - Using dynamic lists, SelfServicing, it has a pretty good example.

I have found with llblgen, in most cases if you can figure out how to do it in SQL it can probably be done using llbl.

Unrelated to your problem: Why not name all your PK fields like <EntityName>ID for example PositionID.

Gabe

Just for clarification is a position simply a predefined query?

A Position is a way for the administrator to predefine a query on a set of users. They would be able to filter by location, job, and other entities specific to this application. Basically, any other entity that is related to a User can be used in the Position Filter.

How will positions be defined? One time by an admin? Or will there be a UI?

We have talked about redefining the way that the position is created. We are going to store the entire query in the PositionTable instead of trying to run it every time a user needs to determine their position(s). Every addition will run the query to add the records from the position filter into a "PositionUser" table. If the Position is updated, then the current records in the PositionUser table are deleted, then the query is run again to keep the list of users correct. The same goes for any of the entities, but mostly the users.

Also, there is a GUI for this in the administration of the application. Check out the Smart Playlist in iTunes. We are going to base it on this (but with more options, etc...)

Will this only return one type of entity? If so you could just add the predicates when you fetch a collection.

It will always return a PositionID and a UserID (So a PositionUserCollection).

Unrelated to your problem: Why not name all your PK fields like <EntityName>ID for example PositionID.

I would rather call a PositionEntity.ID than be redundant and use PositionEntity.PositionID. Just preference =)