What I'm thinking about is generating an interface for each entity. After searching the forum I've found a couple of related posts and one in particular advised that this was unnecessary because it was basically just redefining the entity definition. And what good is an interface that is only implemented in one class...

I guess my angle is, what if Otis hits the lottery (Do they have lotteries in Europe?) and punts LLBLGen in favor of a nice long vacation.

I think by generating these interfaces and coding against them I can remove the dependency on LLBLGen Entity's from the UI code. Plus if i introduce manager interfaces as well...

IEnumerable<IMessage> GetMessages(){}

vs

EntityCollection<MessageEntity> GetMessages(){}

I can really make strides towards a DAL/BLL agnostic framework. Has anyone ventured down this path with LLBLGen before? Thoughts?

Yes we do have lotteries, no I never win anything in them

Seriously though: You cao do this. You can automate this btw. In the designer, you can specify additional interfaces for an entity. You can specify a macro there so you don't have to re-type the entity name. With some additional templates, you can generate the interfaces in separate files and be done with it .

Keep in mind that it is actually pretty much overkill, as the interface might give you loose coupling, but that doesn't mean your logic and your software isn't coupled to the persistence framework used. That's the fallacy of 'persistence ignorance' or 'poco': it doesn't exist: your software relies on the aspects of the persistence framework used, how it queries, how it manages entity graphs in memory, how you can persist graphs etc.

I can see how the business logic will be more tightly coupled to the persistence framework. But do you agree that you should be able to completely remove the dependency from the UI? I think a nice side effect of this and other approaches is that it helps to ensure business logic stays in the business layer which is the driving force behind not allowing objects like DataAccessAdapters and the associated dynamic query objects into the UI layer...

I guess manager classes can get you part of the way by hiding the adapters and query objects but in the past I've always returned EntityCollections and Entities. Also I've always exposed methods like Save, Get, GetAll and I think manager classes would be more useful with methods like (think messages for example) MessageManager.MarkAsRead(Entity) instead of letting the UI set the IsRead field and call MessageManager.Save(Entity)

Which following the gist of this thread leads to what I would consider the next step

MessageManager.MarkAsRead(IMessage)

Now the UI doesn't know about adapters, predicates, OR entities

Otis wrote:

Yes we do have lotteries, no I never win anything in them

Seriously though: You cao do this. You can automate this btw. In the designer, you can specify additional interfaces for an entity. You can specify a macro there so you don't have to re-type the entity name. With some additional templates, you can generate the interfaces in separate files and be done with it .

Keep in mind that it is actually pretty much overkill, as the interface might give you loose coupling, but that doesn't mean your logic and your software isn't coupled to the persistence framework used. That's the fallacy of 'persistence ignorance' or 'poco': it doesn't exist: your software relies on the aspects of the persistence framework used, how it queries, how it manages entity graphs in memory, how you can persist graphs etc.

I'm also quite interested in this approach. I spent a few years at clients & projects where i couldn't convince the client to use LLBGen, and was forced to use nHibernate & Linq2Sql (although in my last week at the previous client, they intended to review LLBLgen - and i KNOW once they take a serious look at it, they won't ever use anything else again

But now i'm at a new client, greenfield project (WPF smartclient). I'm relatively new to WPF, only did some small stuff, but I am confident that it's really cool and convinced that i'm gonna like it.
I am also in the position to convince the client to use LLBLgen for their datalayer (on oracle10g), and will probably choose the adapter paradigm. My idea is to design it so that the smart client will use WCF to fetch entities from the backend. Now i thought it might be a good idea to make interfaces for the entities, and let WCF return those. That way we can eliminate every dependency to llblgen in the smart client project. So my question : are there "out of the box" templates for generating these interfaces ? So that for an CustomerEntity we could generate an interface:

public interface ICustomer 
{
   string Name {get;set;};
   string LastName {get;set};
   IList<IOrder> {get;}  // <-- is this even possible due to co-variance ?
   //etc
}

On a last project, we didn't use interface for our business objects, but we just wrapped every linq2sql generated entity in a "domain object"...the constructor of the domain object took the entity as argument, and copied all properties. Lots of manual coding & maintenance

Any other thoughts on how to tackle my problem ?

On a side note, things like http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=15204&HighLight=1 frighten me a little bit and make me wonder is my approach is gonna work in the long run ..it's a several man-year budgetted project, and my ass could be on the line here

(sorry for the double post ..i got an asp.net error after posting and retried - again an error but it seems it worked both times)

HcD wrote:

(sorry for the double post ..i got an asp.net error after posting and retried - again an error but it seems it worked both times)

Yes, the errors keep re-occuring more often, though we never run into them unfortunately, so we can't really reproduce them. The server logs also don't show an error log. We think it's a timeout, though aren't sure. We're looking into having a better error reporting service setup, so we can find out what's causing problems.

Otis wrote:

HcD wrote:

(sorry for the double post ..i got an asp.net error after posting and retried - again an error but it seems it worked both times)

Yes, the errors keep re-occuring more often, though we never run into them unfortunately, so we can't really reproduce them. The server logs also don't show an error log. We think it's a timeout, though aren't sure. We're looking into having a better error reporting service setup, so we can find out what's causing problems.

it's for sure no timeout - i also got the error on the post where i excused for the double post

For the subject of my question, my idea is to have the WPF smartclient talk to the backend via WCF, and use llblgen adapter model. But i really think it's best not to reference the ORMsupportclasses in my wpf project, so i'd like to have interfaces for my entities (my "domain interfaces" ) and pass these over WCF ... is this doable ? Are there allready templates for this interface generation ?

Thnx in advance, Sven.

Edit : i did indeed again receive the server error when posting, and i prepared my message in notepad then copy-pasted it - so a timeout is not possible

Not much too see though ;-) :

Server Error in '/TinyForum' Application.
--------------------------------------------------------------------------------

Runtime Error 
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.