Transaction script is Antipattern?
Well there is a similar topic about transaction script with NoSQL database, but this one is about the pattern in general. From what I find about Transaction script, it is not object-oriented at all. Its basically procedural code despite the fact that it may use objects in every line of its code.
The better solution is to use a domain model instead, coupled with either active record or a data mapper with unit of work/identity map/lazy load/query object and such. Transaction script may be easy to use, but it is really procedural programming and therefore should be considered an antipattern in object oriented world.
What do you think? Do you agree with transaction script being antipattern? Or do you actually have a way of designing a transaction script that is object oriented instead of procedural in disguise? I doubt this is possible though.
Answer
Transaction Script is definitely not an anti-pattern.
From what I find about Transaction script, it is not object-oriented at all.
You are right, it is not, indeed. That fact however doesn't make it an anti-pattern. Although it is a procedural approach, indeed, it still has its right place in the series of business logic architecture patterns - you just have to know in which case it is a best practice to use it - and in which case it isn't. Simply put: if your problem domain is very simple then it isn't worth the overhead to use a more complex pattern in your business logic.
Or - as Fowler writes:
When to Use It
The glory of Transaction Script is its simplicity. Organizing logic this way is natural for applications with only a small amount of logic, and it involves very little overhead either in performance or in understanding.
The anti-pattern you might think about is called Anemic Domain Model. This is the case when you intend and think you are building a Domain Model - because your problem domain is complex enough for that, - but you actually end up in a Transaction Script - because of bad code organizing / weak OO skills.