Hot answers tagged business-logic
20
Short Answer : Business logic should really be in the model. You should be aiming for fat models, skinny controllers.
You should start from your controller logic. On update, your controller should direct your code to method/service that delivers your changes to the model.
In the model you may create helper/service classes where your business rules or ...
14
Your colleagues are conflating architecture with implementation.
The idea behind a multi-tiered application is simply that it's broken up into parts that encapsulate certain kinds of processing (storage, business logic, presentation) and communicate with each other using well-defined interfaces. Just as it's possible to successfully do things that resemble ...
13
ElYusubov's answer mostly nails it, domain logic should go into the model and application logic into the controller.
Two clarifications:
The term business logic is rather useless here, because it is ambiguous. Business logic is an umbrella term for all logic that business-people care about, separating it from mere technicalities like how to store stuff in ...
11
Business logic doesn't go into the database
If we're talking about multi-tier applications, it seems pretty clear that business logic, the kind of intelligence that runs a particular enterprise, belongs in the Business Logic Layer, not in the Data Access Layer.
Databases do a few things really well:
They store and retrieve data
They establish and enforce ...
11
Stored procedures are powerful enough to let you code a violation of three-tier separation by bringing business logic into the RDBMS layer. However, this is your decision, not an inherent flaw of stored procedures. You can limit your SPs to servicing the needs of your data layer, while keeping your application logic in the application layer of your ...
7
To truly isolate business logic and make it separate from the presentation layer infrastructure, it should be encapsulated by application services. The MVC architecture is a way to implement the presentation layer and it should remain at that scope, delegating all business logic to these application services. Think of view models as adapters between the view ...
6
In an ideal (service oriented multi-tier) world UI should communicate to a business layer through data contracts and a service facade. The UI should not need to know anything about the actual business layer or the entities and methods the business layer works with. So a UI and service facade would share a data contract definition (these can be simple ...
6
While it is true, that the standard enterprise architecture is pretty close to the three-layer model, truth to be said, it actually means harder maintenance.
If you grab an SVN/CVS/git/... log of an enterprise application with considerable history, you'll find out, that the rate of change is as follows:
views change all the time
models change about as ...
6
Though you are describing this as a shared coding session (I can't call it pair programming, as only one person is "driving" - in pair programming, both parties take the keyboard and write code), I would call it gathering acceptance criteria.
That is, you are validating business rules (correct calculations and processes) with the business user (though one ...
5
You and large parts of the programming world seem to misunderstand what the roles of the MVC parts are. In short, they are:
Model = domain logic
View = output logic
Controller = input logic
This means that the model is responsible for the entire business logic: anything that is related to drawing widgets on a screen, driving a printer, outputting data as ...
3
I am a strong believer in keeping business logic out of the database as much as possible. However, as my company's performance developer, I appreciate that sometimes it's necessary to achieve good performance. But I think it is necessary far less often than people claim.
I dispute your pros and cons.
You claim that it centralizes your business logic. On ...
3
It sounds like what need is to have your programs digitally signed (i.e. Code Signing). This is similar in concept to an SSL certificate, in that it proves that the program is from whomever the certificate was issued to & has not been modified (e.g. malicious code added).
The thing key difference to understanding Code Signing though, is that the ...
2
The fact that your book says you should always code in that model is a red flag that it is not a good book.
Different situations call for different paradigms and design patterns. If you feel that that pattern would fit, go ahead and use it. Otherwise, go with what you're comfortable with.
However, don't get caught in the trap of thinking well it won't be ...
2
I am not familiar with the standard displayed in your example. However, process modeling tools are many. Some use static diagrams (e.g VISIO and the likes) and some can generate code (see links below to name a few). One of the most used standards in processes modeling is the Business Process Modeling (BPMN 2.0. Once you define the conceptual process in BPMN ...
2
I have worked in 2 different companies that had different vision on the subject.
My personal suggestion would be to use Stored Procedures when execution time is important (performance). Since Stored Procedure are compiled, if you have a complex logic to query the data, it's better to keep that on the database itself. Also, it will only send the final data ...
2
There's a middle ground that you need to find. I've seen scary projects where the programmers use the database as nothing more than an overpriced key/value store. I've seen others where the programmers fail to use foreign keys & indices. On the other end of the spectrum, I've seen projects where most if not all of the business logic is implemented in ...
1
Depends on what you mean by business logic. Any "logic" that gives meaning to contents of the model should be in the model. In the linked question, the highest voted answer seems to define "business logic" as anything relating to data; this makes sense from the point of view that a business' data is its business!
I once saw an example by the creator of ...
1
It really depends on your usage of stored procedures and business requirements.
There are a number of projects that do use a three-tier architecture and depending on the nature of business requirements there might be need to shift some operations to a data tier.
Speaking about terminology, in general words these tiers described as:
The presentation tier, ...
1
I suggest you spend some time knowing about data modeling. I see that it is an essential skill to get acquainted with even if you don't use RDBMS.
we don't have the customer id in the order entity and we have a list of order entities in the customer entity.
This is clearly a design mistake. The business rule is:
Each Customer has 0,1,more Orders
And
...
1
Putting the business logic inside the model might sound the best way to go. The controller receives a call from the remote web app. The controller on the MVC web service takes the call and redirects the execution to a method in BL. Now, Business Logic can be contained in the 'Model', but can also be positioned in some other folder, say, 'Business Logic'. So ...
1
As always, it depends on the complexity of the project.
In trivial applications, where the domain model complexity is relatively small, you can put the logic in the models and call it a day.
However, for non trivial applications with complex models and lots of business rules, it's better to separate things a little bit more.
If you put the business logic ...
1
how should I pass user input from the UI to the BL, as a bunch of strings passed to the BL method and the BL will build the object from the parameters, or should I build the objects inside the UI submit_function and send objects as parameters?
Sending Objects as parameters are preferable by me. Advantages:
In case if we need more parameters in future, to ...
1
A service is an interface. A method/function is an interface. A service should be for overcoming changes to the physical layers, not logical layers.
You could even have a single logical layer that is split over several physical networks and communicates with itself. So services should not be a hard-line for splitting logical layers. They are for ...
1
Here's how I typically build my n-tier applications, in this case, let's use an MVC web application project.
A class library, typically called: ProjectFoo.Domain:
Here's where I create my abstract repositories for accessing data. For example:
public interface IAccountRepository
{
IEnumerable<Account> FindAll();
}
I also create my concrete ...
1
The three-tier model is well-suited for business applications, of the transactional variety (i.e. multiple user accessing a database). For other types of applications, such as games, highly interactive user interfaces or other real-time data processing, I wouldn't necessarily reach for a multi-tier model, however. So it depends on the nature of the ...
1
With regard to 1. and 2.
What you're describing doesn't really sound like a 'state machine' to me (And i'm afraid that I couldn't make much sense of the example in the context of what you described).
A state machine typically involves transitioning between known states when a a condition is hit for that particular state; it sounds more like you're trying ...
Only top voted, non community-wiki answers of a minimum length are eligible
