Hi Frans -

I'm writing an LLBLGen Pro Framework here that supports both Self-Servicing & Adapter.

I've been able to work very successfully with IEntityCore, IEntityFieldCore, and IEntityCollectionCore.

However, my DeleteTracker class needs to reference a UnitOfWork. And I just realized - there is no IUnitOfWork, just UnitOfWork & UnitOfWork2. This is really limiting because I'm not able to call common functions like .AddForSave() & .AddForDelete(). And I now may need to create a DeleteTracker and DeleteTracker2 class.

Why is there no IUnitOfWork? Any specific reason?

And would you please add this into v3.0?

Thank you very much -

Ryan

PS 1.) Also missing an IEntityViewBase or similar - we only have IEntityView & IEntityView2.

PS 2.) Also missing an IEntityFieldsBase or similar - we only have IEntityFields & IEntityFields2

There are no interfaces because they're only used for one purpose by one class. I.o.w.: the adapter specific class has a different interface than the selfservicing one, so a specific interface would be redundant.

The only purpose for the interface would be for code which AND had to do persistence AND has to support both template groups. That will run into problems anyway, as you need persistence specific code for both template groups anyway. The methods on UnitOfWork are different from the ones on UnitofWork2, as they're close to how things work in adapter (e.g. refetch requirements, which aren't necessary in SS etc.). So the interface IUnitOfWork would contain different methods to make it workable for both template groups (so a 3rd interface if you will). I didn't think that was really useful because the two classes were already different (and released).

IEntityViewCore is probably an interface which could be added as both IEntityView(2) interfaces share common methods. I'll look into that but can't promise anything, as these interfaces by themselves aren't necessary to make the framework work as it should. Same goes for the interfaces on fields

This is sadly the side effect of starting with the wrong template group and then adding another one with the restriction to not break anything already released. It would have been much better if we would have started with adapter and made selfservicing a specialization of that but alas, we can't reverse time

No problem, Frans.

What I've done since Yesterday's post is create Container classes. For instance, I now have a UnitOfWorkContainer(Of TUnitOfWork). So, I pass in a UnitOfWork or UnitOfWork2, and use this one class throughout my Framework for the common methods I need. Each application using our Framework will not need to know about UnitOfWorkContainer.

I've also created an EntityViewContainer(Of TEntityView), which now supports datatable projections across both EntityView & EntityView2. Works for now.

Thanks for your reply -

Ryan