Tag Info

Hot answers tagged

39

The business logic should be placed in the model, and we should be aiming for fat models and skinny controllers. As a start point, we should start from the controller logic. For example: on update, your controller should direct your code to the method/service that delivers your changes to the model. In the model, we may easily create helper/service ...


23

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 ...


22

Expected: None Desired: A lot A programmer who understands the business analytics of a company or industry is much more valuable to that company than an amazing programmer who only knows how to code what he is told. My suggestion would be to learn whatever you can about the industry you are programming for. It will increase your value to employers in ...


21

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 ...


19

How much business and systems knowledge should a programmer have ? As much as is needed to solve the problems of your clients. In some cases, it may be minimal. However in many cases, like the one you describe, it is a lot. As @Rachel noted, the better you understand the domain, the more valuable you are to your employer/clients. How does one go ...


19

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 ...


15

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 ...


13

If you mean representing individual business rule checks with exceptions, then I don't think it's a very good idea. Many times you have to report more than one failed condition, and not stop on the first one. On the other hand, I do believe that checking for all rules and then throwing an exception with the summary is a good practice.


13

Business logic almost always has to run on a server you control, for security reasons. If by "server" you mean "web server", then I agree, it doesn't need to have almost any business logic. But you almost always need an application server with the business logic, whether that's inside a database or a web server or is separate and called by the web server. ...


11

Not technically impossible, but... Scheduling resources, with the goal of finding the ideal schedule that maximizes the use of time slots. I was on a project once, in my earlier computing days, that had this requirement. I worked on it awhile before I realized that it was NP-hard. Other examples of problems that are not technically impossible, but are ...


10

I agree with several others here: it sounds like you need to learn more about how to learn the business domain quickly. Journalists do this a lot. When I was in your position a long time ago, I picked up a couple of textbooks on journalism and reporting. I learned a lot from them. Background reading is important; in this day and age, Google is your ...


10

Finding a suitable model isn't always straight forward. It is one of these things which require more experience than plain knowledge. However, the following simple recipe might help you to get over an initial mental block. It was originially described in this paper by Abbott and is frequently referred to as "Abbott's textual analysis". Write a plain text ...


10

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 ...


9

Always try to understand the business domain before writing any code. Read a book on it and talk to the users/domain experts until you are confident you truly understand your task. Depending on the business domain, this isn't always easy, especially in the beginning. But as time passes and you gain more experience you'll be able to craft good software for ...


9

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 ...


8

If you're feeling weird about it or you're getting push back from others, try using the term "Domain Logic" instead.


8

In the example you've given us I think that raising an exception is a bad idea. If you know that the user is not authorized before they start working and you still allow them to do some function and then smack them with an message AFTER they've already completed the task, that's just a bad design. Using exceptions to enforce business rules is not a good ...


8

That sounds like an eminently sensible decision to me. MVC is a presentation pattern, therefore business logic and persistence operations have no place in the UI layer of the application. Ideally an MVC model is just the data you are presenting to be rendered by the view. This is not at all necessarily the same as an equivalent domain entity - for instance, ...


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 ...


7

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 ...


7

Your primary difficulties I feel are that you have a mismatch between a very linear and custom workflow in an older application that do not coincide with the user interaction workflows that are common on the web. Web applications that interact with a server application that contain the business logic communicate in a Request/Response messaging style. The ...


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

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

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 ...


6

A few pieces of advice. First, use an analogy - pretend you were implementing this without computers, such as doing it by mail (not E-mail). As you add features, visualize the form customers fill out getting more and more complex. Think about the increased breadth of skills required by staff and the number of staff required to fulfill each function. Talk ...


6

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 ...


5

I don't see what value throwing an Exception has in creating good business logic. There are dozens of approaches to handling business logic that do not involve using a system that is meant for addressing unexpected conditions in the operation of a system. It is expected that in business logic, conditions will not be met; that's the reason for having it in ...


5

If you consider that a Customer is a part of the domain model, then it makes sense (especially within the context of DDD but not limited to it) to have have both properties and operations for that object. With that said, however, I think that the example you've used is a poor one, and is a cause of the argument. If you're talking about persistence, then ...


5

You are probably working in a in house IT developer shop. It is a different wold there. Companies with in house developers don't want the best programmer they want a programmer that will add the value they want to the company right now if not yesterday. They don't want to think about the business rules because they expect the developer to know them it's why ...


5

I would focus on use-cases and user-stories. I could document them, perhaps in a wiki, and give each one an ID (like UC00001). Then when I wrote unit tests and/or integration tests, I'd label them with the use case they inform. Then when I get to two unit tests that can't both pass because they're mutually exclusive, I'd throw those two use cases back at ...



Only top voted, non community-wiki answers of a minimum length are eligible