Tag Info

New answers tagged

1

It is helpful to distinguish two types of access control: Vertical - functions that some users can access and some users cannot. For example, anyone can view the home page, but only admin can ban a user. Horizonal - functions that multiple users can access, but the data is segregated. For example, everyone can access "inbox" - but they see only their own ...


-2

It doesn't seem to me these layers are really separate unless they are different applications entirely. Though the idea of separate classes like BL and DAL etc sounds good, I rather think the UI should only handle UI functions and receive from the BL only strings and numbers in an expected order to be passed into the appropriate controls. The BL can ...


1

absolutely awesome practice. also try having some sort of base controller that have all other of your controller extended to it to avoid repetitive access control check. let's say i want to limit people from visiting the profile controller, i can have a parent controller called user and right in the constructor i would do a check to see if user has access ...


5

It is perfectly acceptable to put security/permissions logic in the controller method. The purpose of the controller method is to coordinate service calls to the service layer or business logic layer or repository. Technically, security is an orthogonal, but very important concern to the business logic methods. It is orthogonal because it essentially ...


0

Typically, the DAL has no knowledge of the BLL. Think of it this way, a different application with a different BLL could use the same DAL. A Payables application/module and a Receivables app for the same company would share data (clients, charges, payments, etc.). Trying to have one DLL have knowledge of more than one BLL would be very difficult and ...


-1

Its better that you make DllCustomer be the superclass of BllCustomer to solve your connundrum So here is how your code would look like: class DllCustomer { //Database CRUD Operations } class Customer extends DllCustomer { //All the customer related logic } So you can pass around the Customer object around c = Customer.find_by_id(1) //method ...


0

Business rules are rules that exist in the problem domain that define or restrict processes in that domain. These are rules that may be applied by software. The use cases are documented observations of the business rules in practice. Example, if the problem domain is prescribing, then: a business rule could be "Can't do refills on Control-II ...


2

Heres an excerpt from wikipedia It is a rule that defines or constrains some aspect of business and always resolves to either true or false. Business rules are intended to assert business structure or to control or influence the behavior of the business Business rules describe the operations, definitions and constraints that apply to an ...


-1

You could call the business logic where you decide what you will do with the data that you got from the user. There you can manipulate it and return or save on database. What you do with that data depends on the client needs.


8

People use the terms "business rule" and "business logic" to refer to the portion of your application that is specific to your application and represents the core behavior of how things are supposed to work as opposed to generic functionality that could be useful in software written for a different client/business/customer base or code that exists to support ...



Top 50 recent answers are included