Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > .NET > Other .NET > LINQ
Password Reminder
Register
Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
LINQ Discuss Microsoft's LINQ (Language INtegrated Query) for .NET 3.0 and later.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the LINQ section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developersí questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
 
 
Thread Tools Display Modes
  #1 (permalink)  
Old May 29th, 2008, 05:16 AM
Friend of Wrox
Points: 2,376, Level: 20
Points: 2,376, Level: 20 Points: 2,376, Level: 20 Points: 2,376, Level: 20
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: , , Australia.
Posts: 596
Thanks: 1
Thanked 3 Times in 3 Posts
Default DAL to BLL

Hi All,

I have recently been looking at Linq for my DAL.
I had hoped to utilise the objects generated from Linq to form the base class for my BLL.
It appears that I can't do this because there is no way to filter the Linq context before it becomes an object, so if I want to utilise the object returned from a linq query in my BLL I must still assign each property of the linq object returned to my class's property, even though my class inherits from the object returned.

Is this the case, has anyone dealt with this situation before?

I can see an huge benifit to utilizing linq but I dont want to lose the design principles of a good BLL.

The idea of a BLL filled with static methods and having no object is too ugly by far.

I am considering the singleton pattern as a possible out here, but would love to know if anyone else has any other ideas.

Best Regards,
Rod



======================================
"They say, best men are molded out of faults,
And, for the most, become much more the better
For being a little bad."
--Shakespeare
======================================
__________________
======================================
"They say, best men are molded out of faults,
And, for the most, become much more the better
For being a little bad."
--Shakespeare
======================================
  #2 (permalink)  
Old May 29th, 2008, 11:50 AM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,409
Thanks: 0
Thanked 16 Times in 16 Posts
Default

While I have done little concrete plumbing of LINQ to my own DAL/BLL I would hesitate to base my own classes off of the classes generated by LINQ. My perspective is that the LINQ generated code often too closely models the underlying data architecture so some level of abstraction is desirable to decouple a BLL class from the DAL, be it your own or purely the LINQ to SQL data context.

I've been thinking about this issue myself lately and will very soon be diving into some new application work using LINQ. At this point I'm favoring the idea of maintaining my own business object library and handling the plumbing between the data store (SQL) and my object library. I realize this is extra work but until the entity framework is fully operational I'm still not entirely comfortable coupling business logic directly to generated types. For me this breaks the intention of the layer barrier.

Quote:
quote:
The idea of a BLL filled with static methods and having no object is too ugly by far.
I would hesitate to call this "too ugly". I have used what I call the "dumb object" architecture for a while. The business objects are essentially nothing more than data structures and there are business layer classes that do the work on those classes. Often the business objects are in separate assemblies which keeps them very portable. This is desirable where you might need to use those objects external to business logic processes such as in a distributed application where you connect to an application tier via remoting but want to keep the client app lightweight by not having libraries full of application logic that isn't used.

Another reason I often avoid the coupling of business logic to data - such as in a single business data/logic class, or "smart object" - is that of volume (for lack of a better term). Often the business layer works with collections of classes. Having a business logic class that contains logic as well as instance data feels clumsy to me when you start to work with multiple instances of the data. I find it much clearer to have a business logic class that can work with one or more instances of a class without each class having its own set of logic hanging off of it.

I'm not sure if that really answers your question, but hopefully it will provide some insight.

-Peter
compiledthoughts.com
  #3 (permalink)  
Old June 2nd, 2008, 11:46 AM
Friend of Wrox
Points: 2,376, Level: 20
Points: 2,376, Level: 20 Points: 2,376, Level: 20 Points: 2,376, Level: 20
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: , , Australia.
Posts: 596
Thanks: 1
Thanked 3 Times in 3 Posts
Default

Hi Peter,
Thanks very much for your input.
I feel that the project I am joining is over-using Linq and simplifying the purpose of the BLL.
The current model links the related classes at the DAL because, I am told, linq does not allow joins between different data contexts. So all the tables are in one data context. It appears to me that the only purpose they currently have for the BLL is to organisationally seperate the static Linq calls.
My hope in using inherited Linq classes was to fill out the simple wrapper classes being used with some business logic and modelling, but as you said I would be bringing the data model up, which is not desired.
I'll have to give the issue more thought and come up with a specific question. However in essence you have answered my concerns, in that, we should have a full BLL to seperate the data model from the business one, regardless of wether linq is used for the DAL.
The issue I face is the extra effort involved in the BLL being used to relate the objects, when linq provides such an easy means to relate the entities it creates.

Thanks again for you time.
I've not been on wrox for a while and I am greatly comforted that your advise is still being shared so generously.



======================================
"They say, best men are molded out of faults,
And, for the most, become much more the better
For being a little bad."
--Shakespeare
======================================
  #4 (permalink)  
Old June 2nd, 2008, 12:15 PM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,409
Thanks: 0
Thanked 16 Times in 16 Posts
Default

Rod,

You are right that extra effort is involved with mapping the LINQ data context classes created for you to your own classes. However, you should be able to so some fairly easy object creation by using the flexible selection that LINQ permits. I.e. instead of selecting the context class, you could select your own class and use the object initializer capability of 3.5 to assign properties to the class instance as part of the select code. This should keep the creation of a collection to the single line of LINQ code. However, this has the side effect of not making it straitforward to return a typed collection because you are using an inferred type. So you will likely still need to do a manual creation of a collection. I still this as a gain because you can utilize LINQ to abstract away the database plumbing code which is the part that's annoying to duplicate.

Good to see you back. I'm still here providing advice because I'm still trying to figure out my own problems. ;) So thinking out these kinds of things helps me too.

Cheers!

-Peter
compiledthoughts.com
 


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
BLL and DAL kss BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 13 November 24th, 2008 02:59 PM
Help with BLL and DAL kss BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 0 November 20th, 2008 08:23 PM
breaking bll and dal into separate projects tony20501 BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 5 November 29th, 2007 11:29 AM
Why not using a common detail class for DAL BLL Ghistos BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 1 April 17th, 2007 01:04 AM
Redundancy in DAL/BLL classes Mourad BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 1 March 8th, 2007 09:39 PM



All times are GMT -4. The time now is 08:19 AM.


Powered by vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.