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
======================================

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.

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

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
======================================

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