October 16, 2015 at 8:02 pm
Hi all,
I'd like to mention the book Expert Business Objects by Rockford Lhokta. One of the principles of the application architecture used in the book is that business logic is attached to, and follows objects on their journey throughout the system. It's a fundamental shift in design process (that takes some time to get your head around).
We can probably argue the caveats of the original question forever, so I thought that proposing an alternative to the question would be refreshing. Why should we have to decide which layer it goes into?
Dallas
October 17, 2015 at 6:43 am
dallas-1069889 (10/16/2015)
Hi all,I'd like to mention the book Expert Business Objects by Rockford Lhokta. One of the principles of the application architecture used in the book is that business logic is attached to, and follows objects on their journey throughout the system. It's a fundamental shift in design process (that takes some time to get your head around).
We can probably argue the caveats of the original question forever, so I thought that proposing an alternative to the question would be refreshing. Why should we have to decide which layer it goes into?
Dallas
Interesting suggestion, Dallas. I'm familiar with Rocky Lhokta, having seen him at conferences. And I appreciate what he has to say. I'll look for that book, thanks for mentioning it.
Rod
October 18, 2015 at 7:24 pm
However, in my current use case, I keep all logic in the database. SQL Server is the BI platform. Everything is batch, everything is controlled by SQL Server.
I have been assuming we've been talking about OLTP web applications. BI ETL processes and other rules are stored at the database. Not even sure I can imagine how that might be different.
October 19, 2015 at 12:38 pm
]
There's data logic, process and workflow logic, and interface logic.
For me this sums it up perfectly. This approach is natural to a multi skilled team.
The debate gets heated when you have separation of skills and the DB guys aren't allowed to touch the code and the programmers aren't allowed to touch the DB. In such a situation no one wants to lose control as fixing something requires two warring factions to declare peace.
October 21, 2015 at 7:15 am
SQL stored procedures in the database.
November 2, 2015 at 8:27 am
I agree with the school of "the right logic in the right layer". One definition of what make the right placing is also what is shared by what i.e. if a database is shared by two systems then I would expect all the logic that needs to be shared across those systems to either be data logic so sit in the RDBMS or operational logic that MAY sit in the middle application tier as reusable components.
Of course logic might be data driven and itself stored as data e.g. routing logic.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 26, 2015 at 4:04 pm
Gary Varga (11/2/2015)
I agree with the school of "the right logic in the right layer".
Me too! 🙂
It usually seems to me that most people tend to take what I would call extremist doctrinaire views on this topic. Even some fairly specific area of business logic will be best split between database, middle layer, and front end.
Providing information and entertainment for a customer, for example, requires a lot of data, and is best done with business logic split between all layers. That requires knowing what customers' preferred languages are (and knowing when they change, whether temprarily or permanently), knowing which information sets are available in which languages, whether a customer has fall-back languages for information which isn't available in his preferred language, and so on. So there's a lot of data in the database, and ensuring that it meets the requirement that its possible values are only those (and ideally all those, subject to capacity constraints) which represent valid states of the real world is business logic (data integrity and expressive adequacy) that definitely belongs in the database. But laying out text depends on display/print device characteristics as well as language-specific (and sometimes customer-specific or individual-specific) layout rules and actually determining the layout needs to be in the front end. Turning customer requests passed in from the front end into appropriate requests on the database, and turning the results of those requests into responses that the front end can convert into something to deliver to the customer doesn't happen in the database or in the front end, it's in the middle layer.
So I very much agree with
xsevensinzx (10/16/2015)
So, to answer the question, "Where should middle tier business logic be stored?" It depends... How tall is a tree? :hehe:
and with
dallas-1069889 (10/16/2015)
Why should we have to decide which layer it goes into?
and with
Chris Harshman (10/16/2015)
There's data logic, process and workflow logic, and interface logic.
Tom
Viewing 7 posts - 31 through 36 (of 36 total)
You must be logged in to reply to this topic. Login to reply