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.
Related
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.
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.
I want an opinion from technocrats,
We are migrating legacy system build in Oracle forms using Oracle 8i
database. Client wants to redevelop this legacy system in web
application so we choose MVC3 framework. Client wants us to re use all
stored procedures of legacy system, which contains business logic of
application.
If every business logic is written in stored procedure than i think we
don't need a Business layer in our system.
So i created three layers -:
Interface Layer -> MVC 3 application
Data Layer -> Used to fetch information from stored procedure
DTO Layer -> Used to transfer data from Interface layer to Data Layer.
I did not created Business object or business layer , since all
business logic is inside Stored procedures. I don't like creating
business layer who just forward request from Interface layer to data
layer and don't have any business layer in it.
Is this approach is correct ?
Business layer is separate project
If the business layer is a separate project, I would focus on the portions which are part of the project. It is entirely reasonable to have an interface layer, with minimal business logic (usually validation logic) in a server side application. You might want minimal business logic in the client to make it more responsive i.e. it doesn't go all the way back to the database to validate input.
You can have the business layer in the database (not that I would do such a thing), or in server side Java, or some of it in the client (not that I suggest doing that either to a significant degree)
I would recommend that you still create a business layer even if it just forwards all the operations to the stored procedures which are part of the data layer.
Since the client wants you to reuse all the stored procedures that have the business logic in them it also sounds reasonable that he will not want you to modify or add any more stored procedures. Events may occur that will require you to implement them differently or change the sequence of a business logic that you can then put into your business layer. Maybe you may need a business logic that is not data-centric - meaning it does not sound reasonable to have it in a stored procedure, like sending an email or coordinating with a third party system.
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