RadGrid driven by a list of BLL objects, not DAL objects

Hi,

For a lot of reasons I want to strictly separate Data Acces Layer classes (i.e. "persistent classes") form Business Logic Layer classes. In other words - let persistent classes stay as created by OpenAcces wizards. All the logic is placed in BLL classes.
Each such BLL class contains an instance of a DAL class and exposes its properties in direct or indirect way.
Some example:
There is a DAL class - "Person". It has two properties: PRName and PRSurname (corresponding db columns are named: PR_name and PR_surname).
And ther is a BLL class - "BPerson":
It's not complete - just an idea, of course.
At the Presentation Layer I don't want to even know about DAL classes.
And then - I want to display a grid with all persons. I ask my database with OpenAccess - but this way I get a list of DAL objects. Therefore I must create a new list of BLL objects (with a BPerson's static method; it returns an ObjectView, ready to ):

 

And at the Presentation Layer I have a simple statement:


Well, it works in general. But what about it's efficiency? I hope that constructing BLL objects (this way) doesn't affect lazy loading of DAL objects?
I would be very grateful for your opinions.

Regards
Tomasz

To completely separate the two, why not return the List() in the first place so your Grid is bound to List<Foo> or IList<Foo> and you don't even have to have an "using Telerik.OpenAccess;" since it's just Dal.GetBusinessPersonList();

Al

Hi,

Sorry, but I don't understand. Could you write a snippet of code how to obtain List<BPerson> list - in your manner?
It seems to me that GetOqlQuery(...).Execute can return only persistent class objects. BPerson is not a persistent class - for example it may hide some columns (make them private).

Regards
Tomasz

Doesn't your result object have  ToList() method?  If not the view certainly does - use that as your return type vice the View.  Here's what I'm talking about - Sorry for the formatting...

So change

public static Telerik.OpenAccess.ObjectView GetAllPersons()

to

public static IList<BPerson> GetAllPersons()

and change

List<BPerson> res = new List<BPerson>();
to
List<BPerson> res = result.ToList(); 
return res;


I only bring it up because you mentioned that you really don't want your presentation layer knowing anything about your DAL but then you are binding your grid to a Telerik.OpenAccess.ObjectView.  If you are just binding to an IList then the data could be coming from an ORM, WebService or whatever and your presentation layer really has no idea.

Some ORM tools have each object maintaining it's own state so the fact that it's part of an IList and not part of some specialized collection doesn't matter, for other ORMs that is not the case and you may lose functionality by not using their specialized collections.  I'm new to this ORM so perhaps the Telerik folks could provide insight into how well it works with theirs.  But for me my UI has no reference what so ever to anything in the DAL (which is what you mentioned) so that's kind of how I do it.

hth
Al

Hi,

OK, clear. But:

• "result" if of IQueryResult type and contains "Person" objects
• the key thing is not to convert it to an IList (because it is already an IList), but to create a new list of BPerson objects
• the relation between Person and BPerson is that a BPerson object includes a Person object; therefore a BPerson object must be created using new BPerson(<Person object>) constructor

So:

• you are right that I can simplify my code by making GetAllPersons IList type and not using all that ObjectProvider and OBjectView stuff
• but the questions remain:
  • how to effectively create a new BPerson list?
  • when the fact that it is just an IList, not an IQueryResult (which adds some properties (as "IObjectContext Context") and methods (as "IMoveableNumerator GetEnumerator")), will make troubles?

Especially the second question is to the Telerik folks - as you have mentioned.

Thanks for advises
Regards
Tomasz

Hi tmlipinski,
The best way to create a list is using a foreach on the result which is an IEnumerable as well.

Sincerely yours,
Dimitar Kapitanov
the Telerik team