My question is really one of building an n-tiered application architecture using Linq.
Currently I use business objects to call the data access layer which in turn does the appropriate Linq query and returns the Linq object (or DTO or EO..whatever you want to call it). I then work with the Linq objects directly, performing business logic and databinding.
In essence I am using Linq objects as business objects in themselves, partialing them out to add business logic. I'm not certain as to whether this is the best way to go about it, or whether it makes more sense to populate the CustomerBO from the Customer Linq object. This is what Rocky does in the CSLA, but then again using this method I can't see what the benefit of using Linq is. Other examples that I have seen do it exactly the way I am and use the Linq objects as business objects.
I guess my question really is: Are Linq entities business objects or simply data transfer objects that should populate ...
Go to the complete details ...