Talk:Business logic
From Wikipedia, the free encyclopedia
Contents |
[edit] What's the difference between a business logic and a daemon?
Technically speaking, not so much I think. The same goes for Web services. It is more of a conceptual thing really. It seems to me that daemons are more likely to be a feature of an operating system than a stand-alone software application though.
- A daemon is not a 'business logic'- end of story. Since I do not know where to begin with all the things that are wrong with your confused and nonspecific answer, I will just let it lie.--Fergie 12:52, 1 June 2006 (UTC)
Daemons are processes run for any purpose, including things such as system mainenance. "Business logic" is supposed to be related to an application at least. (I hope.) Nixdorf 10:29, 1 Mar 2004 (UTC)' ==
- Erm- cant we do a bit better than this?--Fergie 12:52, 1 June 2006 (UTC)
- The logic used by an application, a daemon, a web service, or any other program could qualify as business logic if it is kept apart from other logic used. The point of business logic is so that common processes such as calculating taxes and transportation fees can be changed without changing anything else and so that the same logic can be used in different contexts. For example, an application that calculates taxes and trasportation fees, a daemon that does this calculation automatically, or a web service that does the calculation for a fee might by law be required to use the same business logic for the calculation of taxes and transportation fees. -- M0llusk 03:25, 17 August 2006 (UTC)
I'm curious when this term first started seeing widespread use. To me it feels like something recent... I don't recall hearing it 10 years ago.
[edit] Does business logic mean anything specific?
Personally I have my doubts, and the article as it stands does little to allay them. A citation or two would put old cycnics like me in their place, but if no clear references are found, I think that a vote for deletion would be in order. In my (not inconsiderable) database admin career, I have only heard this phrase muttered in the wooliest of terms by people who, to put it unkindly, were speaking our of their arses. Not that this in itself is a reason to can 'business logic', it is merely an observation. So: sensible definition or VFD--Fergie 12:44, 1 June 2006 (UTC)
[edit] Application vs Business/Enterprise Application
"The core of any application is the business functionality it provides" I am sorry but this quote is just plain incorrect. There are many examples of applications with no affiliation to business needs. grep, cat, many if not most open source applications. Business logic only has meaning in a business or enterprise context. Even then whether it is the "core" of an application is debatable.
[edit] Arghhh! Entering the Dilbert-zone!
My criticisms below referred to the version circa July 2006 [1]. Neale Monks 18:25, 26 October 2006 (UTC)
Sorry, this article reads to me like a pitch from a management consultant. It doesn't explain anything at all. I'm a smart guy with a science degree and a PhD, and I have _no idea_ what it's about.
To actually make sense here, the article needs to explain whay business logic is, give actual examples, define new terms, and so on. For example, how can "logspecific" be used without either linking to another article defining it, or actually defining it within this article? Ditto "business layers", "business processes", "long running transactions", etc.
Cheers, Neale Neale Monks 10:03, 18 July 2006 (UTC)
- Amen--Fergie 09:34, 30 July 2006 (UTC)
-
- I went ahead and nominated for deletion. If experts in the field think this article is worth saving, please go ahead and make the case. I just don't think -- as it stands now -- this article explains anything at all. Neale Monks 15:33, 31 July 2006 (UTC)
[edit] This is a critical concept
Please do not delete this page. This concept has been a critical unifying element of modern business software which has been a major contributor to the recent explosion in productivity in the United States.
Here is my quick attempt a a brief explanation. With more time perhaps I can come up with a draft of this page in an alternative form:
Business logic is a concrete representation of abstract business rules that is usually used in conjunction with a database of business transactions. For example, retail transactions may include sales taxes, per customer purchase limits, a small credit for not needing a bag, and so on. By keeping the business logic apart from the storage of the data it is possible to use the same business logic with different data or with different applications, for example summarizing periodic sales performance or calculating yearly taxes by using the same data that came from the cash register program and which is checked for validity using the same logic. Encoding business logic is a strategy used by enterprises with complex data or transactions to minimize the cost of automating their operations. Without using this strategy the cost of developing software applications for automating business processes may become prohibitive. -- M0llusk 05:40, 8 August 2006 (UTC)
[edit] The meanings for 'Business Logic' suggested so far...
Mainly from the vote for deletion page. People who have expressed an opinion think that Business logic can mean one or more of the following:
1)A mid-level abstraction layer in a multi-tier architecture
2)The logic of business processes (any type of logic, any type of business) --Fergie 09:26, 17 August 2006 (UTC) 3)Nothing. Yet can be used as filler in situations where the speaker wishes to use an impressive sounding software-engineering term (such as promotional material for expensive software). In other words the term is notable precisely because it is vague meaningless software terminology.
4)Various confused definitions containing combinations of random strings of buzzwords such as 'business rules', 'enterprise' and 'business objects' a la point 3 above.
Are there any more meanings that I have missed? If so- please note them here.--Fergie 07:44, 8 August 2006 (UTC)
-
- The picture in the article explains the concept i'm most (and only) familiar with. In all my software engineering classes, that is the definition always given to us, and the layer separations we should be making. It is correct about coupling and interweaving; strong coupling is bad in object oriented design, and diametrically opposed to seperating business/presentation/data logic. Interweaving creates unmaintainable code that is more apt to break and require more test cases.
-
- I'm inclined to agree with a previous posting, too: reading the article in its current state does make it mostly useless, since it only has a picture and a single section, "Location of business logic," that describes the only definition i've ever heard: It is the logic done in response to a user action to fetch data.
-
- It may be best to merge it in with an article more related to software engineering that describes common distinctions made between parts of an application. (Further more, I've never heard it used anywhere except in a software context. daemon process - Never; Money/corporate business - Never)
-
- In any event, it shouldn't be deleted because its an important part of good software design, and does have a real meaning in software engineering. Merging it into another section may be more applicable than deletion.
--24.4.211.92 09:05, 9 August 2006 (UTC)
-
- This characterization shows a lack of understanding of the context. For example, as typically applied, both number 1 and number 2 are the same. The context in which this is used is software engineering, that is people working to produce various types of software to automate business processes. Whether or not business people are aware of how that works does not have any real meaning. Most people do not understand sewage treatment, but have a grasp of the idea of toilet water being processed for safety before dumping. When software was initially used to automate business processes the designs were monolithic. All logic used was bunched together such that rules for accessing a particular database technology were mixed up with rules for generating pictures with specific graphics technologies so that any change to the business logic would lead to complicated rewrites and redesigns. Keeping business logic apart from other logic reduces production costs of business software so dramatically that new types of automation become possible. Should we also delete the hedge fund and short sale pages because those descriptions may not work for all laymen? -- M0llusk 03:38, 17 August 2006 (UTC)
-
-
- FYI, this is a thread to list all of the suggested meanings of business logic that have been made on these pages, you might want to understand the context a bit better yourself. Anyway, onto your opinion: You are describing modularity and encapsulation. Are you saying that you think either of these is a synonym for business logic? If so I will list them up--Fergie 09:26, 17 August 2006 (UTC)
-
-
-
-
- Your comments are garbage. My response was to discussion of the meaning of business logic and made direct reference to the implications of the asserted lack of meaning. The larger context here is a Wikipedia dominated by deletion crazed luddites. Oddly enough there are some listings on Monster and other job search sites offering excellent salaries to anyone who can generate or manipulate business logic, so these listings might be a source of information. You are arguing for everything to be redefined in ways that make the verbiage work for you, but the world is not like that. Business logic is code for representing business processes. Ideally it would be both modular and encapsulated, but it may not be. Why do you hate the real world examples business logic is used to describe so much? How can you calculate taxes and shipping and handling charges without some calculation? -- M0llusk 06:09, 16 September 2006 (UTC)
-
-