What Class Am I?

This post and the following pithy remark by a commenter reminded me of my own question regarding a not-identical but related quandary I posed here.

...by Walky_one:
The basics of object oriented design with polymorphism is:
The base class defines functionality that is COMMON for all derived classes.
Functionality that is NOT COMMON should NOT be in the base class.
I know the UnsupportedOperationException approach (and sometimes I even agree that it's a workable way): However it's still an approach that violates one of the most central aspects of object oriented design...

Transactions are a Business Concern

Transactions are not a persistence concern, they're a business concern. As such, DAOs shouldn't be transactional, your service layer should be.

- Barney http://www.briankotek.com/blog/index.cfm/2008/1/11/Thoughts-on-Adding-Nested-CFTRANSACTION-Support-to-ColdFusion

...typically you want service method to behave transactionally instead of just DAO methods - if you have 2 updates in service method and second one fails, transactions don't help you to have DB consistent (but it depends on your business logic)

- Betlista http://stackoverflow.com/q/10298483

Update: Unrelated but the notion that "business concerns" or "business/domain logic" belongs in a "service layer" may boil down to semantics that are directly dependent on architectural style chosen, e.g. SOA vs DDD (see discussion at http://programmers.stackexchange.com/questions/218011/how-accurate-is-business-logic-should-be-in-a-service-not-in-a-model).

Downside of Law of Demeter

Author indicates pass through methods (or new parameters added just to pass through?) are a necessary evil of LOD:

The downside is a number of "pass through" methods that do nothing but forward the message to the next child object... Like many OO guidelines, it's probably impossible and impractical to follow this one 100% of the time. The balance between spreading knowledge and adding overhead is a judgment call but I generally vote for more encapsulation until the overhead becomes too painful. 

http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/LawOfDemeter.htm

Mutability Key to Imperative Logic

The only reason imperative logic (a.k.a instructions) execute in sequence is that due to the presence of mutable stored values, the result is dependent on the evaluation order. Using your vocabulary, an "instruction" can (and a "rule" cannot) operate on mutable values. – Shelby Moore III

http://stackoverflow.com/questions/602444/what-is-functional-declarative-and-imperative-programming

Two-tier vs. N-tier

Two-tier approaches, while allowing more rapid development, are inherently less scalable than N-tier solutions (such as Web-based database solutions).[citation needed] In a two-tier solution, there must be one connection to the database for each concurrent user, whereas with N-tier solutions, which incorporate connection-pooling technology, a limited number of database connections - sometimes, just a single connection - are multiplexed among a much larger number of actual concurrent users.

http://en.wikipedia.org/wiki/PowerBuilder

Law of Demeter

The issue here is that LoginPage is breaking a the Law of Demeter. LoginPage is asking for the Database even though it itself has no need for the Database (This greatly hinders testability as explained here). You can tell since LoginPage does not invoke any method on the Database.

http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/

Separating Programming from Presentation

"In other words, Velocity doesn't remove programming from presenation; rather it requires users to learn a new ad hoc scripting language. By requiring Web page designers to learn the Velocity Template Language, Velocity fails to eliminate the mingling of the content and presentation." http://www.learningace.com/doc/5903174/2b2d80be66064d5c810bebcd444b927c/j-jsptags