LINQ and 3-Tier
We have established coding standards using strongly-typed datasets in our 3-tier model--very close to the model presented athttp://msdn2.microsoft.com/en-us/library/aa581771.aspx.We are trying to figure out how we should introduce LINQ into this model.We currently have all data access code in the .xsd and business logic at seperate BLL level.With LINQ, it seems that our .dbml replaces the strongly-typed dataset, and that LINQ code should be used at the next level up in our BLL.Is this proper or should we use partial classes utilizing LINQ at the .dbml level to extend its functionality and leave pure business logic in the BLL?
The .dbml file is like your typed dataset, the designer creates an entity class that maps your database table and contains relation between tables as well. The code that uses the entity class, the one with LINQ query can be written in the business logic layer. Just if you don't know, Linq can query typed dataset as well, so you can avoid to create the data access layer back.
Best,
Fabio
Hello,
I have also a question about this.
We have our logic layer. We use the data layer like List<Customer> GetCustomers(); (Customer class is in BLL)
Can we use LINQ without putting linq code into this classes?
We currently use no datasets but building the objects by the results of the sql queries.
hope you understand.
Dirk
If you have a method : List<Customer> DataLayer.GetCustomers() which builds the objects by the results of sql queries... it can instead build the objects by the results of linq queries.
The Customer type is clearly known to the DataLayer, so internally it can
var query =
from c in DB.Customers
select new Customer(c.Name, c.Address, c.Hobby, c.CustomerID);
List<Customer> ResultList = query.ToList();
return ResultList;
To use the example that David gives, there is no need for LINQ attributes on the Customer class. It can be a standard class with nothing related to LINQ.
Only DB.Customers is based on LINQ to SQL.
But then I loose the object tracking capabilities, don't I?
Because I create a Logic.Customer object from each DB.Customer, and then work with the Logic.Customer in my app.
Fabrice MARGUERIE wrote: