I am writing an ntier website which contains a table of information. I am using jeditable to make the table editable.
The client wants some fields in the table readonly depending on whether the information they contain is before or after a particular date. Should the readonly logic reside in the business layer or the ui layer?
Regards Si
Both. Your UI should check those non-editable fields an then no provide controls to modify the fields and also, for security, your business layer should also disable that functionallity.
Business layer. The before or after date rule could change - it's business logic.
The business layer should execute the rule and communicate the fact to the UI layer. It should be enforcing the immutability on its end regardless of what the client does.
Related
I'm developing N-Tier application in C#. Server side consists of this layers:
Data access layer (EF Code First Entities and DbContext)
Business layer (contains all business logic and objects)
WCF Service layer (per-call instanstiated services that expose some operations from business layer)
Now client requests are processed in this way:
Client creates Request DTO and sends it to Service layer
Service layer maps this DTO to business object and calls BL method
Business layer does something useful, makes requests to DAL, and then returns some business object to service
Service layer maps business object to DTO Response and returns to client
It works nice despite code duplication which is mitigated by Automapper. The actual problem is this:
Client shows same objects in different views: grid, form, etc. For example, grid(list) view requires only Id and Name from User object, while Form(details) view needs every User's property. But Business layer knows nothing about views. It can only provide full UserBL object to Service calls and then it's the Service responsibility to map this UserBL to UserListDto or UserDetailsDto. And for some heavy objects, fetching extra fields from DB become a performance issue.
So, should Business layer provide different methods for different client operations? I don't like this solution because it looks like domain logic polluting, but I don't know what else could be done.
Client shows same objects in different views: grid, form, etc. For example, grid(list) view requires only Id and Name from User object, while Form(details) view needs every User's property. But Business layer knows nothing about views. It can only provide full UserBL object to Service calls and then it's the Service responsibility to map this UserBL to UserListDto or UserDetailsDto. And for some heavy objects, fetching extra fields from DB become a performance issue.
I usually return different representations of a business entity depending of the type of action that is made in the BL. For instance when searching a return a search representation of user which just contains the minimal set of properties required to identity a user. When fetching a specific user I return a complete business object.
Regarding your issue with code duplication. It is not duplication. Those different representations of a user have different responsibilities.
DTO: Responsible of transferring a user and creating a loose coupling between the business layer and the consumer
BO: Responsible of encapsulating and performing business operations
DB entity: Responsible of making the BO object persistent ignorant
Thus if you would use only one representation of a user you would merge all those responsibilities and therefore have to do sacrifices in good design to be able to use it everyone. The only really gain is that you have to write a few lines less code. Keep that in mind when you start to maintain the released application. You saved a few lines, but got a lot harder application to maintain.
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.
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.
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.
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.