Three-Tier architecture and LINQ to Entities
-
10-07-2019 - |
Question
For a couple of years, I've been using the three-tier architecture (Presentation, Logic and Data Layer) to write applications. Usually, I am using tools such as .netTiers to generate the data layer and partially the logic layer. Everything is well defined and I love it.
I am now constraint to use LINQ to Entites (it appears that LINQ to SQL was abandoned by Microsoft) and I am really confused. It looks to me like the code generated by LINQ to Entites is a big mix of the logic and data layer on which I have very little control. In addition, I don't really like the fact that I have to use the classes (entities...) generated.
In the end, could you share your experiences and best practices with LINQ to Entities? Any idea how I could still have a well defined Three-Tier architecture?
Thanks!
Solution
Ian Cooper wrote good series about architecting application using Linq2Sql:
- Part 1 Introduction
- Part 2 Layered Architectures
- Part 3 DAOs and Repositories
- Part 4 Dynamic Queries
- Part 5
- Part 6 Mapping with XML files instead of Attributes
- Part 7
- Part 8
- Part 9
- Part 10
Hope you find what you need.
OTHER TIPS
L2S is not dead, but it is basically complete. Its an implementation ( Sql Adapter ) for Linq. Linq is a language feature and will continue to expand as .net versions are released.
What makes Linq beautiful is the simplicity. I for one, beyond additional providers ( like MySql, Firebird, etc... ) I don't really want them to muck it up.