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.
Related
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.
In a 1 tier application i.e Mvc, you get a folder called models and you build and store your classes in there, I'm aware when it comes to a three tier application from what I have read it seems correct to store the models inside the business layer (2nd tier), and from the UI (first tier) I would add a project reference to the 2nd tier which will allow me to use the models and make calls to methods.
From the second tiers perspective it would call the data layer (third tier) and perform crud operations against the database, but the data layer would require the models from the business layer so when I try to add a project reference from data layer to business layer i get the error
A Reference to "Business Layer" could not be added, adding this project as a reference would cause a circular dependency
Which I understand as a reference has already been made via business layer to data layer
How would I get around this? do I create additional models in the data layer and populate them with results from the database and pass that back to the business layer which then passes it back up to the UI? I'm slightly confused on this.
** Update **
From what I have read for the data layer to reference models inside the Business layer I would need to do model mapping, My model mapping will be quite large so I'm thinking of including a 4th tier which will be a shared library and that will consist of all the models that way the data layer and the business layer can access the models as and when is required.
A little off topic but ...
Depending on the size of your application, there may be no reason to introduce unnecessary complexities to try and follow pattern you may not necessarily understand. Doing so, will cause you extra headache.
That being said, if your project is of a large size and requires some good organizing, I would strongly suggest more research and maybe a few sample project in where you try out the architecture you came up with. No way you'll get it right the first time.
I would personally suggest looking into "onion architecture" instead of "n-tier", and of course you'll find many different views on it. You'll have to make your own decisions.
Here's a generic set-up I would start off with.
Core. It knows about no other project. This is where your classes with your "business" go. Such as Customer, Product, Order, etc.
Data. It knows about Core. It is responsible for taking in a Core object and storing it somewhere. That is all.
Service. It knows about Core AND Data. It's job is to expose methods such as "Create Customer", it will be responsible for creating a customer and storing it.
Web / Api / Mvc. This will know about Service. It's job is to expose your service to the user. (UI and such). (It may also know about Core / Data ... but that's a larger discussion.)
You're on the right track but I find it easier to think of the model layer as the data (third tier), the controller (business layer, second tier) manages the flow of the data between the ui (first tier) and the data layer.
If you modify your architecture this way, you should get rid of the circular references.
This also allows you to map your data layer objects to the appropriate less/more complex structures of the middle tier in a way which simplifies the interface shown to the UI and encapsulates the business logic there too.
I have been a little confused with trying to determine where to put the business rules for my application.
I am developing an web application using asp.net conventional web forms (not mvc) and on top of that I have a class library where I have the repository pattern for writing to database. I have a "Business Layer" in the repository pattern and also, I am writing stored procedures to affect the tables.
Where should I put for example, Mandatory field validation rules ?
Other example would be, converting foreign currency to USD (i have an exchange rate table, currently I do it in sprocs).
Would you recommend staying away from the sprocs for rules and build everything in my repository business layer ? or In what cases do you recommend building rules and validations within the sprocs ?
This answer is appropriate if you develop a small application that does not use multiple data sources or does not have an extensively unit-tested business layer and if you do not plan to add a service layer (such as for caching). See the opposition in the comments.
If I may, I can suggest to:
Remove repository pattern completely. Do you really need to support multiple databases?
Keep business logic in a business layer, not database. The benefits are in the locality of the rules. All your domain is expressed as a set of conditions, rules, strategies etc. And it is all located in one place. Should you choose to store them in a database you would create yourself additional headache when maintaining the code.
It is easy to unit test code that is in the business layer. I am not sure if it is possible to unit test SP.
SP and Repository pattern don't go well together.
Currency rate change every fraction of a second, for this you should use a reliable web service that you can call and get a precise value.
Summary:
Stay away from SP
Stay away from repository pattern
Use ORM directly instead of repository pattern abstraction
Don't mix persistence and business rules
Separate your business rules in a separate (reusable) assembly
Your repository is NOT supposed to have a business layer. It's sole purpose should be to act as an abstraction of your database. Inside it you manage how you store/retrieve your application data.
Use SP for database operations that are not subject to frequent change. NEVER put your business logic inside SP. Business logic have tendency to change over time.
You can create a domain-layer where your business objects reside. Your business object should encapsulate their own validation logic.
Other than your business/domain objects you may have utility classes (e.g. CurrencyManager or CurrencyHelper) that actually use your business objects to verify business logic against data.
Finally try to keep your domain free from any sort of presentation/view layer reference. Don't apply business validation rules at view layer or display validation logic at domain layer.
-hope that'll shed some light.
I Am creating a web application and first use Entity Framework. I created Entity Data Model and now I am not sure, how to proceed now.
Premise: My database is really simple (Rating, WebPage, Visitor) and database tables corresponds to the business objects.
My suggestion is 3tier architecture but how to make it?
It is good idea create partial classes with the same name as Entity Framework objects (Rating, Visitor) and declare here new methods (GetAverageRating()...)? Or is better create some VisitorProvider, RatingProvider and place logic here?
It is better use EF objects in BLL and Presentation Layer or I should create my own BO objects on my BLL layer and transform EF object to BO?
I'm think, it is more practical use static methods on my DAL than instantiate classes on BLL. Do you agree?
Can you recommend me some best practices? I have many ideas how to create it, but I do not know what is the right.
3 layer architecture is quite popular but what it really means?
Presentation layer
Application layer
Database layer
If you ask what each layer means you can be pretty sure you will get several different answers. You can further divide each layer into sublayer and build layered hell like:
Client side presentation layer
Server side view layer
Controller layer
Service facade layer
Service layer
Domain objects layer
Repository + Factory layer
ORM layer
Stored procedure layer
Database view layer
Database table layer
WTF? That is just example that application can be easily over architected. It can go even worse if you insist that only neighbours can exchange data and if you decide to add special type of objects to be exchanged between layers instead of flowing sing set of objects through multiple layers.
Add layers which you need to make you more comfortable with developing the application and which will do reasonable separation of concerns and maintainability needed for the scale of your application. You can simply do the most simplest application which will be used just few weeks and must be developed as fast as possible. In such case you can do that within few days simply by using ASP.NET web forms and data source controls (or ASP.NET dynamic data). It can be badly extensible but in such situation it is exactly what you need to implement application quickly. Writing layers and doing all the stuff around maintainability and extensibility is reasonable if you need it. Another quick prototyping technique is ASP.NET MVC Scaffolding which can create quick multilayered skeleton of the application which can be further modified.
Both approaches are correct and it only depends on the approach you like. The first is called active record pattern but it is not used very often with entity framework. The second approach is more popular. You can either use EF directly in some middle class which you called Provider (common name is also Service). This class will do both data access logic and business logic. In more complex applications developers like to somehow wrap EF to separate class following repository pattern and call the repository either from service or directly from web app. code behind or controller (depending on amount of business logic). Try to do it without repository first. My personal opinion is that people should start to use repository only once they understand EF itself.
Again both approaches are correct. In a simple application it is fully acceptable to create EF model with POCO classes (EFv4.x) and use them in all layers. If you are using ASP.NET MVC you can find that you need special classes as view models to fully represent needs of your individual views. In a more complex application you can have separate objects exposed from a business layer - this is especially used if the business layer is exposed as a remote service (WCF).
It depends how you write these DAL methods - it is absolutely necessary to not share the EF context among requests! It also depends if you want to write some test or not. Layer defined by static methods is something which goes directly against testable architecture where you want unit test just single layer (unit testing with EF can be hard). It also depends if you want to use dependency injection which is based on instances.
Good day. I have to pass the session value to a business logic layer, I can pass it to the function from presentation layer but how can I access it directly in my business logic layer ? Also is it a good approach to pass it directly to business logic layer like
GetMyRecords(Count,Session["userID"].toString()); ?
As per John's reply above, you ideally do not want to access any UI elements in your business layer.
You should pass the session values from your presentation layer to the business layer so that the business layer is only aware of the values - not where they are coming from.
As regards your second point about how to pass the values from presentation layer
I would suggest you should atleast wrap Session["userID"].toString()) as a property in your presentation layer.
Because its a property, you can add checking / validation logic if needed.
Also, i find it cleaner to have a wrapper SessionWrapper class and use that in the application for accessing the session values. The advantage of this is that if your Session Persistence changes, its usually a one place change. Of course, this is not necessary as the .NET Session Providers can be plugged in via configuration even if you create your own provider.
I would recommend to not access Session from within the business logic layer. The intention of having separate layers is that they serve different purposes. For example the business logic layer should not - generally speaking - contain any reference to the user interface technology, e.g. Session in this case.
The translation from the presentation layer (aka UI Layer) to what the business layer expects should be done in the presentation layer. Who knows? Maybe next week your boss asks you to move the business logic off that web server and onto an application server and use WCF based communication between them.
Clear separation keeps more (all?) of the paths open for tomorrow even if you don't know how tomorrow will look like.