Hi, i'm currently looking at the following architecture for my LLBLGen Pro 2.0.0.0 project.

WinForms / WinForms CF.NET / ASP.NET | Service Layer (Remotable) | LLBLGen generated DAL | Databases

If possible, i would like to keep the LLBLGen generated code and ORM support classes out of my presentation layer(s). The idea is to have the .NET 2.0 BindingSource as the only way, for the UI developer, to work with data.

            
  AdmissionService admissions = new AdmissionService(...);
  bindingSourceAdmission.DataSource = admissions.GetAdmissionList(...);
  bindingSourceAdmission.Filter = "Department='MKA'";
  ...

But for this I need EntityCollection to implement IBindingListView (Filtering / Sorting). This isn't the case if i'm correct. Do you have any plans to add this in the near future?

In also found the same question in an old post on this forum : http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=2993&HighLight=1

Kind Regards,

MarcVangrieken wrote:

Hi, i'm currently looking at the following architecture for my LLBLGen Pro 2.0.0.0 project.

WinForms / WinForms CF.NET / ASP.NET | Service Layer (Remotable) | LLBLGen generated DAL | Databases

If possible, i would like to keep the LLBLGen generated code and ORM support classes out of my presentation layer(s). The idea is to have the .NET 2.0 BindingSource as the only way, for the UI developer, to work with data.

            
  AdmissionService admissions = new AdmissionService(...);
  bindingSourceAdmission.DataSource = admissions.GetAdmissionList(...);
  bindingSourceAdmission.Filter = "Department='MKA'";
  ...

But for this I need EntityCollection to implement IBindingListView (Filtering / Sorting). This isn't the case if i'm correct. Do you have any plans to add this in the near future?

An entity collection is bound to a control via its defaultview (similar system as the datatable uses), thus via its EntityView. We have no plans to support IBindingListView as we think string-based filtering isn't the way to go, as it can lead to errors at runtime instead of at compile time.

We have no plans to support IBindingListView

Ok.

as we think string-based filtering isn't the way to go, as it can lead to errors at runtime instead of at compile time.

That's very true, i understand your POV. Although i must say that in the project i've been working in for the last 2 years, i've never seen any errors like these make it to production... I think people generally are carefull with these things. In the service layer this argument is more important to me because there's simply much more code. LLBLGen is doing a great job there in compile-time checking the lot.

The reason i was looking in to this "requirement" was the fact that phasing-out LLBLGen in the future (i hope not but you never know) would be somewhat easier (but not easy) if the 100thes of forms don't need to be partially rewritten.

Kind Regards,

I'd generally thought of using string based filters as easier to create, but this kind of filtering sure isn't difficult to understand (from the docs):

// [C#]
IPredicateExpression invoicesFilter = new PredicateExpression();
IPredicate filterElement = (InvoicesFields.OrderID > 11000);
invoicesFilter.Add(filterElement);

Chester wrote:

I'd generally thought of using string based filters as easier to create, but this kind of filtering sure isn't difficult to understand (from the docs):

// [C#]
IPredicateExpression invoicesFilter = new PredicateExpression();
IPredicate filterElement = (InvoicesFields.OrderID > 11000);
invoicesFilter.Add(filterElement);

Thanks Chester, but i already knew that I was rather focussing in this thread on keeping things like IPredicateExpression / LLBLGenProDataSource, ... out of the presentation layer.

MarcVangrieken wrote:

as we think string-based filtering isn't the way to go, as it can lead to errors at runtime instead of at compile time.

That's very true, i understand your POV. Although i must say that in the project i've been working in for the last 2 years, i've never seen any errors like these make it to production... I think people generally are carefull with these things. In the service layer this argument is more important to me because there's simply much more code. LLBLGen is doing a great job there in compile-time checking the lot.

The reason i was looking in to this "requirement" was the fact that phasing-out LLBLGen in the future (i hope not but you never know) would be somewhat easier (but not easy) if the 100thes of forms don't need to be partially rewritten. Kind Regards,

I understand, I hope Microsoft does a decent job with Linq so it indeed is no longer necessary, though I fear they leave important things out of it.

What's a bit of a problem with string-based filters is that it requires a complex parser to cover all the possible filters, then it has to convert the parse tree to field objects and predicate objects, which is a bit of a problem as the code doesn't have access to the factories (as it's inside the ormsupportclasses).