I dont find anything for my Business Logic Layer !! Is it wrong to let my Presentation Layer talking to Data Access Layer ? [modified]
-
Hi, I know, a well designed architecture should not allow a presentation layer to talk to Data Access Layer. Rather Presentation layer should talk to Business Logic Layer and Business Logic Layer should talk to Data access layer. In my Data access layer, I have method
/// <summary> /// Gets the employee. /// </summary> /// <param name="emailAddress">The email address.</param> /// <returns></returns> public static employee GetEmployee(string emailAddress) { using (EmployeeDBDataContext myDbContext = new EmployeeDBDataContext()) { employee empRecord = myDbContext.employees.Where(aRec => aRec.emailAddress == emailAddress).ToArray().SingleOrDefault(); return empRecord; } }My Presentation Layer's job is to display the properties of the employee object directly to the UI, where I do not even need to write any code for that. Ok, now, should I create a thin Business Logic layer just to mediate the call of Presentation layer ? Then, it may look very messy as I will have to create a set of methods in BLL duplicating the method signature from DAL. Would you please tell me what could be a better practice ?
modified on Monday, February 28, 2011 5:12 AM
-
Hi, I know, a well designed architecture should not allow a presentation layer to talk to Data Access Layer. Rather Presentation layer should talk to Business Logic Layer and Business Logic Layer should talk to Data access layer. In my Data access layer, I have method
/// <summary> /// Gets the employee. /// </summary> /// <param name="emailAddress">The email address.</param> /// <returns></returns> public static employee GetEmployee(string emailAddress) { using (EmployeeDBDataContext myDbContext = new EmployeeDBDataContext()) { employee empRecord = myDbContext.employees.Where(aRec => aRec.emailAddress == emailAddress).ToArray().SingleOrDefault(); return empRecord; } }My Presentation Layer's job is to display the properties of the employee object directly to the UI, where I do not even need to write any code for that. Ok, now, should I create a thin Business Logic layer just to mediate the call of Presentation layer ? Then, it may look very messy as I will have to create a set of methods in BLL duplicating the method signature from DAL. Would you please tell me what could be a better practice ?
modified on Monday, February 28, 2011 5:12 AM
My first thought looking at this example is that you are awfully trusting. By that I mean that you are trusting input that has not been validated. What happens if email is an empty string, or not a valid email format? This is the type of thing that a well constructed business layer helps to cope with.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
My first thought looking at this example is that you are awfully trusting. By that I mean that you are trusting input that has not been validated. What happens if email is an empty string, or not a valid email format? This is the type of thing that a well constructed business layer helps to cope with.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
Thanks for your kind reply. I see. So, I got something to do (validating inputs) for BLL. But, I do the validation in Presentation Layer as the validation is highly related to the UI. For example, if the input is coming from a Slider, then, my validation code will use the Slider's property. If my email address is coming from a text box, then, my Validation code will use the text box property to check. Yes, if I use a Regex to validate an email address, I encapsulate that Regex code in a method in my BLL and call that method from my Validation logic in Presentation layer so that the Presentation layer does not look thick. Other than validation, is there anything that I may need to know so that I can involve BLL between DAL and Presentation Layer ?
-
Hi, I know, a well designed architecture should not allow a presentation layer to talk to Data Access Layer. Rather Presentation layer should talk to Business Logic Layer and Business Logic Layer should talk to Data access layer. In my Data access layer, I have method
/// <summary> /// Gets the employee. /// </summary> /// <param name="emailAddress">The email address.</param> /// <returns></returns> public static employee GetEmployee(string emailAddress) { using (EmployeeDBDataContext myDbContext = new EmployeeDBDataContext()) { employee empRecord = myDbContext.employees.Where(aRec => aRec.emailAddress == emailAddress).ToArray().SingleOrDefault(); return empRecord; } }My Presentation Layer's job is to display the properties of the employee object directly to the UI, where I do not even need to write any code for that. Ok, now, should I create a thin Business Logic layer just to mediate the call of Presentation layer ? Then, it may look very messy as I will have to create a set of methods in BLL duplicating the method signature from DAL. Would you please tell me what could be a better practice ?
modified on Monday, February 28, 2011 5:12 AM
Nadia Monalisa wrote:
I know, a well designed architecture should not allow a presentation layer to talk to Data Access Layer. Rather Presentation layer should talk to Business Logic Layer and Business Logic Layer should talk to Data access layer.
According to whom? I don't like these kind of generalizations, as these rules-of-thumb are often used to avoid critical thinking. This specific rule-of-thumb applies to datacentric-applications, not to some game like World of Warcraft. Now to refine your statement; it might be benificial to introduce an abstraction-layer, but it shouldn't be an excercise where you merely duplicate the interface of the datalayer, since that would only eat up your time without providing much benefits. I got a small app that stores passwords - no datalayer. But the issue-manager does have one, complete with caching (only active when using Xml as a datasource for the datalayer) and logging.
I are Troll :suss:
-
Thanks for your kind reply. I see. So, I got something to do (validating inputs) for BLL. But, I do the validation in Presentation Layer as the validation is highly related to the UI. For example, if the input is coming from a Slider, then, my validation code will use the Slider's property. If my email address is coming from a text box, then, my Validation code will use the text box property to check. Yes, if I use a Regex to validate an email address, I encapsulate that Regex code in a method in my BLL and call that method from my Validation logic in Presentation layer so that the Presentation layer does not look thick. Other than validation, is there anything that I may need to know so that I can involve BLL between DAL and Presentation Layer ?
As the name suggests, the BLL is intended for business logic. If you don't have business logic there is nothing to say you need to have this layer in place. I will say, though, that separating the validation, etc, from the presentation should help to make your app more testable because you can use a tool like nunit to test it, rather than relying on randomly pushing buttons.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
Nadia Monalisa wrote:
I know, a well designed architecture should not allow a presentation layer to talk to Data Access Layer. Rather Presentation layer should talk to Business Logic Layer and Business Logic Layer should talk to Data access layer.
According to whom? I don't like these kind of generalizations, as these rules-of-thumb are often used to avoid critical thinking. This specific rule-of-thumb applies to datacentric-applications, not to some game like World of Warcraft. Now to refine your statement; it might be benificial to introduce an abstraction-layer, but it shouldn't be an excercise where you merely duplicate the interface of the datalayer, since that would only eat up your time without providing much benefits. I got a small app that stores passwords - no datalayer. But the issue-manager does have one, complete with caching (only active when using Xml as a datasource for the datalayer) and logging.
I are Troll :suss:
Thank you very much. I liked your answer.
-
As the name suggests, the BLL is intended for business logic. If you don't have business logic there is nothing to say you need to have this layer in place. I will say, though, that separating the validation, etc, from the presentation should help to make your app more testable because you can use a tool like nunit to test it, rather than relying on randomly pushing buttons.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
Thank you very much. Now, I got the direction.
-
Hi, I know, a well designed architecture should not allow a presentation layer to talk to Data Access Layer. Rather Presentation layer should talk to Business Logic Layer and Business Logic Layer should talk to Data access layer. In my Data access layer, I have method
/// <summary> /// Gets the employee. /// </summary> /// <param name="emailAddress">The email address.</param> /// <returns></returns> public static employee GetEmployee(string emailAddress) { using (EmployeeDBDataContext myDbContext = new EmployeeDBDataContext()) { employee empRecord = myDbContext.employees.Where(aRec => aRec.emailAddress == emailAddress).ToArray().SingleOrDefault(); return empRecord; } }My Presentation Layer's job is to display the properties of the employee object directly to the UI, where I do not even need to write any code for that. Ok, now, should I create a thin Business Logic layer just to mediate the call of Presentation layer ? Then, it may look very messy as I will have to create a set of methods in BLL duplicating the method signature from DAL. Would you please tell me what could be a better practice ?
modified on Monday, February 28, 2011 5:12 AM
Just to play devils advocate, couldn't you argue that the EmployeeDBDataContext is in fact your DAL and the code snippet should be part of the BLL? If the purpose of the DAL is to allow you to change your data source without affecting the business logic, then I would say the EmployeeDBDataContext achieves this.
"You get that on the big jobs."
-
Just to play devils advocate, couldn't you argue that the EmployeeDBDataContext is in fact your DAL and the code snippet should be part of the BLL? If the purpose of the DAL is to allow you to change your data source without affecting the business logic, then I would say the EmployeeDBDataContext achieves this.
"You get that on the big jobs."
Thank you very much. Yes, thats a good question. Actually, I spent many hours just to find out if that given code snippet should be a part of BLL or DAL. Yes, if I place that snippet in BLL, then, the auto generated LINQ to SQL data context can be the DAL. But, in my BLL, I wanted see the object, not the LINQ to SQL Data context. Because that data context is auto generated and I will have to depend on what Microsoft gives. That is much uncomfortable for me. But, I learned in many place that, Projection should not be done in DAL. Query is a Business Logic. So, the dilemma is kind of a headache and brain killing. Finally I decided to encapsulate the DataContext in DAL and the DAL will not do any projection. DAL will return a single row of a entity or a collection of entity. My BLL will use that collection of entity and use LINQ to Object to do any projection as needed. Even according to that decision, yes, you are right, the above snippet should be in BLL. I should have asked a collection of employees in DAL from BLL and then, the BLL would filter out with the email Address for the desired employee object using LINQ to Object. Hmmm Brain got jammed again :)
-
Thank you very much. Yes, thats a good question. Actually, I spent many hours just to find out if that given code snippet should be a part of BLL or DAL. Yes, if I place that snippet in BLL, then, the auto generated LINQ to SQL data context can be the DAL. But, in my BLL, I wanted see the object, not the LINQ to SQL Data context. Because that data context is auto generated and I will have to depend on what Microsoft gives. That is much uncomfortable for me. But, I learned in many place that, Projection should not be done in DAL. Query is a Business Logic. So, the dilemma is kind of a headache and brain killing. Finally I decided to encapsulate the DataContext in DAL and the DAL will not do any projection. DAL will return a single row of a entity or a collection of entity. My BLL will use that collection of entity and use LINQ to Object to do any projection as needed. Even according to that decision, yes, you are right, the above snippet should be in BLL. I should have asked a collection of employees in DAL from BLL and then, the BLL would filter out with the email Address for the desired employee object using LINQ to Object. Hmmm Brain got jammed again :)
Definitely with Entity Framework, LINQ to SQL and alike have blurred the borders but even in more traditions architectures, the presentation can still be exposed to the entities which encapsulate the data. There is no reason why a DataGrid in the presentation can't display a collection of entities. It looks like LINQ is querying your DB but if the DataContext is actually your DAL then LINQ is actually querying your DAL. LINQ just offers a flexible approach to communicating with the DAL as opposed to the old way of having to write a method (in the DAL), for every possible permutation the BLL may request. So instead of the DAL deciding what the BLL can and can't request. The DAL just provides access to the data source and describes the data. The BLL is free to do what it is supposed to: decide what the presentation can and can't access. What I have just said may be technically wrong but that's how I see it conceptually.
"You get that on the big jobs."
-
Hi, I know, a well designed architecture should not allow a presentation layer to talk to Data Access Layer. Rather Presentation layer should talk to Business Logic Layer and Business Logic Layer should talk to Data access layer. In my Data access layer, I have method
/// <summary> /// Gets the employee. /// </summary> /// <param name="emailAddress">The email address.</param> /// <returns></returns> public static employee GetEmployee(string emailAddress) { using (EmployeeDBDataContext myDbContext = new EmployeeDBDataContext()) { employee empRecord = myDbContext.employees.Where(aRec => aRec.emailAddress == emailAddress).ToArray().SingleOrDefault(); return empRecord; } }My Presentation Layer's job is to display the properties of the employee object directly to the UI, where I do not even need to write any code for that. Ok, now, should I create a thin Business Logic layer just to mediate the call of Presentation layer ? Then, it may look very messy as I will have to create a set of methods in BLL duplicating the method signature from DAL. Would you please tell me what could be a better practice ?
modified on Monday, February 28, 2011 5:12 AM
My collegues and me just had the same discussion this week. Why do all the extra work if you could simply directly get your data from the DAL? Well, I think that this is because sooner or later your client is going to call and they want some new functionality or improvements. So now you have one form where your employee is called, but in a few months you will have two forms. If you seperate your DAL from your UI you then could simply re-use that same BLL you used earlier. If you did not seperate your UI from your DAL then you will find that: A. you need to type some code containing logic (either the LINQ query or validation logic) twice. Or B. you'll have to make a BLL after all to not resort to solution A. Solution A is definately not good practice and if you find your clients demands rising you will type more code multiple times. Even worse, if the client wants the logic you now build into different forms to be slightly different, you are going to have to edit all forms that use this logic, and this is easily forgotten if your application is getting larger. But you do not want B either, because it will cost you a lot of time (first decoupling DAL from UI and then build the extra layer). So building that extra BLL might look like a lot of work now, but it could save you a lot of work in the future. Hope this helped. Good luck with it :thumbsup:
It's an OO world.
-
My collegues and me just had the same discussion this week. Why do all the extra work if you could simply directly get your data from the DAL? Well, I think that this is because sooner or later your client is going to call and they want some new functionality or improvements. So now you have one form where your employee is called, but in a few months you will have two forms. If you seperate your DAL from your UI you then could simply re-use that same BLL you used earlier. If you did not seperate your UI from your DAL then you will find that: A. you need to type some code containing logic (either the LINQ query or validation logic) twice. Or B. you'll have to make a BLL after all to not resort to solution A. Solution A is definately not good practice and if you find your clients demands rising you will type more code multiple times. Even worse, if the client wants the logic you now build into different forms to be slightly different, you are going to have to edit all forms that use this logic, and this is easily forgotten if your application is getting larger. But you do not want B either, because it will cost you a lot of time (first decoupling DAL from UI and then build the extra layer). So building that extra BLL might look like a lot of work now, but it could save you a lot of work in the future. Hope this helped. Good luck with it :thumbsup:
It's an OO world.
Thank you so much for the ideas. Yes, you are right and thats what I am realizing now. At this moment, I am avoiding the extra BLL layer, but I will keep a sharp eye when duplication of code is apparent, and only then, I will add the BLL with only the refactored common methods. So, some of my UI will call DAL and some of my UI will call BLL and over time, depending on BLL will be increased and DAL dependency will decrease.
