Hi there,

I've searched the forum for an answer to this question, but could not find any related posts.

We've added a property to one of our entity classes in the default C# way (partial class, getter, etc.). When retrieving the value of this property we execute some code that uses the adapter from the DBSpecific part of the generated code.

The question is: is this allowed?

Personally I think this smells wrong, but I can't really put a finger on it.

I'd like to hear your thoughts on this matter.

Yours, Gerben ten Wolde

Personally I think this smells wrong, but I can't really put a finger on it. I'd like to hear your thoughts on this matter.

I share the same feeling with you, it smells. It's better to have the DBGeneric classes abstracted from the DBSpecific one, so it can be shared with more tiers without fearing of being used to access the database.

I recommend not referenceing the DBSpecific in the getter of your custom property bu rather use a BL method which access the database and fills this property for you.

Walaa,

Wouldn't this cause a circular reference?

The BL method would be defined in a separate assembly. This assembly would need to reference the DBSpecific dll to access the definition of the generated entity it works with.

Referencing the BL assembly in the DBSpecific project to get the properies value would then generate a circular reference.

Please correct me if I'm wrong.

Regards, Gerben ten Wolde

Referencing the BL assembly in the DBSpecific project to get the properies value would then generate a circular reference

I don't understand, why would you reference the BL assembly in the DBSpecific project ?

Walaa,

We would like to use the BL function in the DBSpecific project so the result of the BL function may be used as a the return value of a custom property on a llblgenpro entity. This would allow us to databind to the custom property (readonly) in grids and such.

Regards, Gerben ten Wolde

Client --> DBGeneric (Entities) --> Business Layer --> DBGeneric

I think Walaa means that you have a function on the BusinessLayer which looks something like

CustomerEntity GetCustomerEntityWithAdditionalPropertyFilledIn(int ID)
{

   CustomerEntiity toReturn;
   using (DataAccessAdapter DA = new DataAccessAdapter)
   {
      toReturn = DA.FetchEntity(toReturn)
   }

  toReturn.YourCustomProperty = 23 //or code to fetch from database

  return toReturn;

}

This avoids the DBGeneric code needing a reference to the business layer.

MTrinder,

Thanks for the example. I understand how this would work now.

However, usefull as this way of working may be in some cases, it has two drawbacks.

1. The property would be writable.
2. The entity can't easily be handled by a LLBLGenProDataSource2 (as far as I know).

It might be insightfull to explain what we are trying to achieve (why we need the DataAccessAdapter in the DatabaseGeneric project in the first place).

We are writing an application that uses organizations and suborganizations (departments) in a hirachical tree. At several places in the application we need to show a path that consists of the name of a selected organization and all its parent organizations. We would like to extend the organization entity with a property that builds this path on demand. To implement this we need the DataAccessAdapter.

The reason we would like to have this information available as a property is that it would be possible to bind to it.

Maybe we just have to live with the smell .

Regards, Gerben ten Wolde

Accessing the DBSpecific dll from the DBGeneric dll is very error prone.

Accessing this custom entity property at a client which has no physical access to the database, would cause an exception. (eg. in case you send the entity over the wire)

The main idea in the Adapter model (and hence the name), is to have the DBGeneric classes separated from the underlying layer to be as mobile/portable as possible to be shared accross different layers of the solution.

You may decide to give up this portability or flexibility, if you don't send the entity over the wire.