I'm playing around with entity framework and a gui trying to learn the basics but I have gotten stuck. I have created a database with the code first approach so in my Data layer, I have a db contect and DTOs for storing and retrieving data. Now this layer needs to communicate with my Buisness layer which then talks to my presentation layer. Now the question is how do I transfer data between the presentation layer and data layer? It seems to me that defining the same Model class in all three layers is stupid and cumberstone but I don't want my presentation and data layer to know about each other.
Related
I am using repository patern in c# with onion architecture containing api, application, domain and data layer.
I noticed that in application layer there is a need for data received from data layer to be in a slightly different format. For example application layer is expecting data from data layer such as
GetPeriods()
2017-01-01 2017-01-31 50
2017-02-01 2017-02-28 70
etc
But in section of application layer I would also need to get this data in a single day list format such as
GetPeriodsAsDays()
2017-01-01 50
2017-01-02 50
etc
I want to make sure that I understand both repository pattern and onion architecture correcly, and my question is should I
a) do TransformPeroidsToDays(GetPeriods) in application layer after I recive data from data layer
or
b) do GetPeriodsAsDays() in data layer and have already formated data at disposition for application layer
Absolutely you want to do TransformPeroidsToDays(GetPeriods) in the application layer. The data layer should only be concerned with creating, retrieving, updating, and deleting (CRUD operations) on raw data.
Transforming the data into something else is "business logic" that belongs in the business logic layer, i.e. what you've called the "application" layer. I would recommend calling it the former or something other than application layer since it's not commonly called that; the term "application" usually refers to the entire...well...application.
I am currently implementing a system and I have a question regarding the interaction between different elements in the system with the class that interacts directly with the database (the one opening and closing connections, executing sql queries, etc).
So far, my Business Logic Layer is deferring the construction of all SQL queries (depending on certain inputs) to my Database Access Layer, which in turn would call the database-handling class to execute each query. Note that right above my Business Logic Layer is the GUI.
The question is: would it be bad practice to include the construction of SQL queries in the Business Logic Layer? I am asking this because I need to implement a procedure that gets data from database DB1, manipulates it, and then writes it into DB2. Thus I find that hardcoding these SQL queries would be easier to keep in my business layer.
Please let me know your thoughts and if this is a clean design to some extent from an architectural point of view, or if I should include this logic all in my Database Access Layer.
would it be bad practice to include the construction of SQL queries in the Business Logic Layer?
Most likely. The business layer should generally be database-agnostic.
I need to implement a procedure that gets data from database DB1, manipulates it, and then writes it into DB2
So you need two data layer objects - one to get the data from DB1 and one to save it in DB2. The "manipulation" can be done in either place (business layer or data layer), depending on the nature of the manipulation. For example, is it purely a data conversion, or does it depend on other aspects of the business layer?
You don't need to bring this logic to Business layer at all.
Follow this steps
Request data from DB1 from the business layer
Data Access Layer returns the Data from DB1 to Business Layer
Manipulate the Data in Business Layer. (Calculations, transformations and what not)
Request the Data Acess Layer to insert this new Data to DB2 and pass along the processed data to Data Access Layer
Data Access Layer writes to DB2
This way is more elegant and you can keep your current architecture unchanged.
EDIT
You can create a separate Data Access Layer for accessing DB2 and have the Business layer call it on step 4. That way you can keep Data access layers more coherent.
If I have a C# application with a 5 layer architecture, much like what is presented here http://msdn.microsoft.com/en-us/library/ee658109.aspx, and I take the strict interaction approach of allowing a layer to only interact with the layer below, I am running into trouble when getting data in my Data layer and passing that data back up to my Business layer.
For example, if I have a business object called MyObject that is defined in my Business layer, but information needed to construct an object of type MyObject is retrieved from the database in the Data layer, my Business layer needs a reference to my Data layer in order to interact with the database. But, my Data layer then also needs a reference to the Business layer, since that is where the MyObject definition lives and the Data layer needs to construct an object of that type from the database results and give that data back to the Business layer. Now we have a circular dependency between the Business layer and the Data layer.
I am wondering what the proper approach is to solve this problem.
I have thought about using DTO objects defined in my Data layer to pass information back to the Business layer. This would work since the Business layer is able to interact with the Data layer, but not vice versa. It just seems like this might be an awful lot of duplicate code to basically mimic the business object definitions in the Data layer.
I also thought about creating interfaces for all of my business objects and putting those interfaces into a separate project that both the Business layer and Data layer can interact with. That way, I can pass instances of the interface and the only common reference between the Business layer and Data layer is the project where the interfaces are defined. I don't see many implementations of this either.
I am wondering what others have done to solve this problem.
Sounds like you would benefit from AutoMapper.
https://github.com/AutoMapper/AutoMapper/wiki/Getting-started
Each layer of your application should have it's own "version of the truth." The data layer has POCOs that are shaped based on the storage format of the data. Then your interface between data and business layers should take those data POCOs and map them into business POCOs. Rinse and repeat for the business/ui boundary or any other layers you may have.
The shape of the data that describes an object best in one layer shouldn't dictate how another layer can best describe an object. (i.e. The data layer might need foreign key ids, but the view can do just fine with an in-memory reference.)
If you need to construct the data on the Data side, then define the type in the data access layer. If the object is constructed in the DL, then that's where the type belongs. This allows you to avoid the circular reference. Just reference the Data project in the business layer project, and you have access to the type.
Another solution is to return raw results from the data access layer, and construct the object in the Business layer from the raw results.
How to develop program/website and minimize DB dependencies using C#.NET?
For example I have made some changes in my DB, after that I must rewrite half a project.
The strategy it to split your application to a different logical layers abstracting the data storage layer from the business logic and UI.
So a simple example will be to have:
Data Layer - your database engine;
Data Access Layer - code which will know how to read and manipulate data from the Data Layer;
Business Layer - will know how to represent Data Access Layer object within your data domain;
Presentation Layer - to display/edit Business Layer objects.
For not very complex domains you can use technologies like LINQ to SQL or ADO.NET Entity Framework to act as 2-3 layers.
Read about Repository pattern and nhibernate
I have an ASP.NET app with a three layer architecture:
Presentation layer: ASP.NET
Bussiness Layer: C# library.
Data Access Layer: C# library with
ADO.Net Entity Framework objects.
Some methods on Bussiness layer would return ADO.NET entity objects but, data access layer is not visible at Presentation layer I can't do that.
My question is: On a design view, Is it correct to expose Entity Objects in the Presentation Layer? I think I only have to link Data Layer library with ASP.NET app.
Thank you!
It's absolutely desirable to have your entity objects available for use and consumption in your presentation tier. That's what all the work is for.
Binding collection of objects to a grid/listview/dropdown
Splashing a single object (i.e. customer) onto a form for read/update/delete
This makes your life easier by far. Otherwise you'd have to pass string after int after double after string between your presentation and business layers.
These may be Entity objects or even your own POCO objects that were hydrated from the Entity objects.
I would even go so far as to say that your Entites should be in their own assembly separate from the DAL.
I suggest that you look into the concepts of View objects...or Data Transfer Objects (DTO). You might consider using a tool like AutoMapper or similar which will create a view specific domain object out of your entities. In general you may have screens that need an entity present to perform its work. But more often than not you will need to pass several different entities. In this case you are better off creating one DTO that contains all of these entities. By doing this you are adding a layer of separation between your presentation layer and your business layer. Often times your entities have more power than you might want to expose to your presentation layer. And...vice versa. Frequently you may need to get some UI messages out to the presentation layer based on some validation flagged in your business layer. Rather than make your ui more complex than it needs to be (by passing in your full entities) you can only pass in what the UI needs in the form of the DTO. Also, there is never a need for your business objects to care about anything specific to the presentation layer. I suggest that you not databind directly to anything as far back as the data access layer. Technically your presentation layer should know as little as possible about your business layer. In the case of MVP or MVC this is very easy to achieve by disconnecting the front end and the back end by way of this additional separation!
I think no, it is not, the best way to do that is to separate data classes from behavior, and reference only data classes in presentation level.The good approach I think to use WCF see this link
See Supervising Controller and Passive View
If you pass the Entity, you are essentially Supervising controller. Otherwise you are Passive View.
Supervising controller is less work, but less testable. Supervising Controller also says databinding is OK.
Passive view is testable but a LOT more work. No databinding. Lots of properties.
Typically I stick with Supervising Controller. You typically don't need that level of testability and it isn't worth the extra trouble.