DAL issue
-
i am using a three tier architecture , while in my dal i generate it from sql to link generator , so in this way my user interface can directly reference to my dal generated although i am calling dal from my middle layer , am i following the wrong approach ? my user interface sholuld just know only my domain objects and my middle layer but its not in the case of linq ? why ?
Tauseef A Khan MCP Dotnet framework 2.0.
-
i am using a three tier architecture , while in my dal i generate it from sql to link generator , so in this way my user interface can directly reference to my dal generated although i am calling dal from my middle layer , am i following the wrong approach ? my user interface sholuld just know only my domain objects and my middle layer but its not in the case of linq ? why ?
Tauseef A Khan MCP Dotnet framework 2.0.
Tauseef A wrote:
ut its not in the case of linq ?
Yes, it is still the case with Linq. Your implementation and understanding is incorrect. Adding Linq to SQL or Entity Framework does not negate a properly implemented nLayer architecture. Your presentation layer should only know about the entity objects, either via DTOs you create at the business layer or self contained Entity objects produced by EF. To remain loosely coupled the presentation layer should not make direct calls to the data layer, or have any knowledge of it.
I know the language. I've read a book. - _Madmatt
-
Tauseef A wrote:
ut its not in the case of linq ?
Yes, it is still the case with Linq. Your implementation and understanding is incorrect. Adding Linq to SQL or Entity Framework does not negate a properly implemented nLayer architecture. Your presentation layer should only know about the entity objects, either via DTOs you create at the business layer or self contained Entity objects produced by EF. To remain loosely coupled the presentation layer should not make direct calls to the data layer, or have any knowledge of it.
I know the language. I've read a book. - _Madmatt
how ? when we generate classes so it generates all the dto's and its data base methods in the same class or same library , so how is that possible that we can make these operations hide from UI layer ? can you please give me any example reference .?
Tauseef A Khan MCP Dotnet framework 2.0.
-
how ? when we generate classes so it generates all the dto's and its data base methods in the same class or same library , so how is that possible that we can make these operations hide from UI layer ? can you please give me any example reference .?
Tauseef A Khan MCP Dotnet framework 2.0.
You are mistaken. Using EF the entitites are created with properties corresponding to the columns in the database table. There are no methods for accessing the database from these entities. Access is via the ObjectContext implementation which has an overloaded constructor that accepts a connection string. You can create a instance of this class in your data layer.
I know the language. I've read a book. - _Madmatt
-
You are mistaken. Using EF the entitites are created with properties corresponding to the columns in the database table. There are no methods for accessing the database from these entities. Access is via the ObjectContext implementation which has an overloaded constructor that accepts a connection string. You can create a instance of this class in your data layer.
I know the language. I've read a book. - _Madmatt
-
but these dto's and datacontext operations are created in the same class library so we can refer all the stuff from the UI . rite ?
Tauseef A Khan MCP Dotnet framework 2.0.
Don't allow the ObjectContext to be created outside of the layer you wish it be used in. EF is complex but your making it to be more complicated than it is.
I know the language. I've read a book. - _Madmatt
-
Don't allow the ObjectContext to be created outside of the layer you wish it be used in. EF is complex but your making it to be more complicated than it is.
I know the language. I've read a book. - _Madmatt