Data Access (DAL, Linq to Entity queries, other functions...)
Business Logic (FACADE, methods to perform CRUD operations, it only calls DAL methods)
Presentation (Webforms)
Typically I insert a row as:
Presentation:
Dim cliente As cliente = New cliente
cliente.nombre = ucCliente.nombre
cliente.nif = ucCliente.nif
cliente.direccion = ucCliente.direccion
cliente.codpostal = ucCliente.codpostal
cliente.pais = "ES" ucCliente.pais
cliente.provincia = ucCliente.provincia
cliente.municipio = ucCliente.municipio
cliente.telefono1 = ucCliente.telefono1
cliente.telefono2 = ucCliente.telefono2
cliente.movil1 = ucCliente.movil1
cliente.movil2 = ucCliente.movil2
cliente.fax = ucCliente.fax
cliente.email = ucCliente.email
cliente.url = ucCliente.url
cliente.cuentabancaria = ucCliente.url
Dim clienteFacade As New ClienteFACADE
clienteFacade.AgregarCliente(cliente)
Business Logic
Imports Model.EntityFramework
Imports DataAccess
Public Class ClienteFACADE
Public Function AgregarCliente(cliente As cliente) As Integer
Return New ClienteDAL().AgregarCliente(cliente)
End Function
End Class
Data Access
Imports Model.EntityFramework
Public Class ClienteDAL
Private m_eDespachoContext As edespachoEntities
Private Property eDespachoContext() As edespachoEntities
Get
Return m_eDespachoContext
End Get
Set(value As edespachoEntities)
m_eDespachoContext = value
End Set
End Property
Public Sub New()
eDespachoContext = New edespachoEntities
End Sub
Public Function AgregarCliente(cliente As cliente) As Integer
eDespachoContext.clientes.Add(cliente)
Return eDespachoContext.SaveChanges()
End Function
End Class
I'm not sure if this way is a correct architecture or maybe it will be better to remove BusinessLogic(FACADE) and write code in Presentation as:
Dim clienteDAL As New clienteDAL()
clienteDAL.AgregarUsuario(usuario)
What do you think which approach would be better? Do you advice any anti patron or bad practice?
Good thing is that u already start to use ntier architecture. There is no spicific rule to apply P & P but worth use it. if you can use it with your own separation of logic in a decoupling way (minimize inter dependancy), i think it is a good architecture.
If the business logic is only about CRUD operations, then I don't see any wrong in moving it to the presentation layer. But remember it's not a good practise to directly call the database from presentatoin layer. So do not remove the DAL layer. For the sake
of simiplcitiy, and if and only if you don't use any calculations and validations, you can move the business logic layer in to the presentation layer.
Edit: @Kelmen: In 4 layer architect, we seperate the DB layer from DAL. So there is a seperate layer for Entity Framework. It's not wrong to integrate Entity
framework in DAL. But it's not wrong to have it seperately too.
...In 4 layer architect, we seperate the DB layer from DAL. So there is a seperate layer for Entity Framework. It's not wrong to integrate Entity framework in DAL. But it's not wrong to have it seperately too.
When we use "layer", it typically allow to replace 1 layer with no/less code impact to other layers.
if decision changed not to use EF, is it really that simple EF can be replace without affect DAL?
as far as I have used the EF, it can't. replacing the EF mean replacing DAL.
Unless you are doing all your DAL in database through stored-proc, which is not what EF been designed for.
as far as I have used the EF, it can't. replacing the EF mean replacing DAL.
Not really. Let's say you use LINQ to Entities to communicate between the EF and DAL. Then there is no need to change the DAL. You just have to change the LINQ to Entities Implementation. You can simply have LINQ to Entities in the EF layer and call it from
the DAL. Then if you need to change the EF, then you would have to change only the EF layer.
riestra
Member
40 Points
149 Posts
Entity F. and 4-layer architecture on Webforms.
Feb 20, 2013 08:04 PM|LINK
Hi;
I separate my solution on 4 projects:
Typically I insert a row as:
Presentation:
Dim cliente As cliente = New cliente cliente.nombre = ucCliente.nombre cliente.nif = ucCliente.nif cliente.direccion = ucCliente.direccion cliente.codpostal = ucCliente.codpostal cliente.pais = "ES" ucCliente.pais cliente.provincia = ucCliente.provincia cliente.municipio = ucCliente.municipio cliente.telefono1 = ucCliente.telefono1 cliente.telefono2 = ucCliente.telefono2 cliente.movil1 = ucCliente.movil1 cliente.movil2 = ucCliente.movil2 cliente.fax = ucCliente.fax cliente.email = ucCliente.email cliente.url = ucCliente.url cliente.cuentabancaria = ucCliente.url Dim clienteFacade As New ClienteFACADE clienteFacade.AgregarCliente(cliente)Business Logic
Imports Model.EntityFramework Imports DataAccess Public Class ClienteFACADE Public Function AgregarCliente(cliente As cliente) As Integer Return New ClienteDAL().AgregarCliente(cliente) End Function End ClassData Access
Imports Model.EntityFramework Public Class ClienteDAL Private m_eDespachoContext As edespachoEntities Private Property eDespachoContext() As edespachoEntities Get Return m_eDespachoContext End Get Set(value As edespachoEntities) m_eDespachoContext = value End Set End Property Public Sub New() eDespachoContext = New edespachoEntities End Sub Public Function AgregarCliente(cliente As cliente) As Integer eDespachoContext.clientes.Add(cliente) Return eDespachoContext.SaveChanges() End Function End ClassI'm not sure if this way is a correct architecture or maybe it will be better to remove BusinessLogic(FACADE) and write code in Presentation as:
What do you think which approach would be better? Do you advice any anti patron or bad practice?
Thanks in advance!
cnranasinghe
Star
8885 Points
1798 Posts
Re: Entity F. and 4-layer architecture on Webforms.
Feb 21, 2013 03:39 AM|LINK
Good thing is that u already start to use ntier architecture. There is no spicific rule to apply P & P but worth use it. if you can use it with your own separation of logic in a decoupling way (minimize inter dependancy), i think it is a good architecture.
riestra
Member
40 Points
149 Posts
Re: Entity F. and 4-layer architecture on Webforms.
Feb 21, 2013 07:01 AM|LINK
Thanks for replying.
But I'm a bit concerned about the approaches I posted it. On your opinion which one is the most recommended?
Thanks.
cnranasinghe
Star
8885 Points
1798 Posts
Re: Entity F. and 4-layer architecture on Webforms.
Feb 22, 2013 01:33 AM|LINK
Seems to be ok. you are refering entity object both in BL and DAL. this is a common approach. keep in mind never to refer DAL stuff from presentation.
Kelmen
Member
180 Points
79 Posts
Re: Entity F. and 4-layer architecture on Webforms.
Feb 28, 2013 05:59 AM|LINK
can you really separate entity framework and dal ?
to me they are exactly in DAL, EF just presenting some features and different accessibility in your biz layer.
more or less, your biz lay is relying/coupling on EF.
Ruchira
All-Star
43056 Points
7040 Posts
MVP
Re: Entity F. and 4-layer architecture on Webforms.
Mar 02, 2013 01:32 PM|LINK
Hello,
If the business logic is only about CRUD operations, then I don't see any wrong in moving it to the presentation layer. But remember it's not a good practise to directly call the database from presentatoin layer. So do not remove the DAL layer. For the sake of simiplcitiy, and if and only if you don't use any calculations and validations, you can move the business logic layer in to the presentation layer.
Edit: @Kelmen: In 4 layer architect, we seperate the DB layer from DAL. So there is a seperate layer for Entity Framework. It's not wrong to integrate Entity framework in DAL. But it's not wrong to have it seperately too.
My Tech blog | My YouTube ChannelPlease 'Mark as Answer' if this post helps you.Kelmen
Member
180 Points
79 Posts
Re: Entity F. and 4-layer architecture on Webforms.
Mar 04, 2013 01:59 AM|LINK
When we use "layer", it typically allow to replace 1 layer with no/less code impact to other layers.
if decision changed not to use EF, is it really that simple EF can be replace without affect DAL?
as far as I have used the EF, it can't. replacing the EF mean replacing DAL.
Unless you are doing all your DAL in database through stored-proc, which is not what EF been designed for.
Ruchira
All-Star
43056 Points
7040 Posts
MVP
Re: Entity F. and 4-layer architecture on Webforms.
Mar 04, 2013 06:52 AM|LINK
Correct.
It depends on how tightly/loosely coupled the two layers. Check out the following article
http://www.wadewegner.com/2009/06/architecting-your-data-access-layer-with-the-entity-framework/
Not really. Let's say you use LINQ to Entities to communicate between the EF and DAL. Then there is no need to change the DAL. You just have to change the LINQ to Entities Implementation. You can simply have LINQ to Entities in the EF layer and call it from the DAL. Then if you need to change the EF, then you would have to change only the EF layer.
My Tech blog | My YouTube ChannelPlease 'Mark as Answer' if this post helps you.