OK i’ll shut up now.

We could almost give that another name..

Three Tiered Database Anti-Pattern

lol

The database was actually the guts and logic behind a really complicated Access front-end that we were replacing, so it makes sense that the logic would be defined in one place (the db) so that our new ASP.NET front end [strike]could take advantage of it[/strike] not break the rules.

Eventually it became a humongous pain in the butt to deal with, because it involved so much more “code” to express logic. Often it required multiple stored procedures and triggers to accomplish things.

We started building out a domain model (a very elementary one, since I didn’t really know what I was doing) but it helped a lot. It abstracted a bunch of advanced rules into one class that we could interact with and sort of “forget” what the database was like underneath. It worked fairly well.

That’s definitely a pattern I’ve seen, and it takes a lot of time and effort (and usually supporting 2 places for “logic” until you can fully migrate away from the db — for logic that is)

This is yet another great launching point. After all the first step to tackling a problem is identification and the Smart UI Anti-Pattern sounds a lot like my particular ailment.

BTW – I haven’t seen you post anything on the ALTDOTNETCONF list — I believe your presence there would be a benefit for you and others. (prod

Thanks yet again Evan for thinking of (generally) and helping (specifically) this self-proclaimed noob.

If you can show me a good DDD application with only value objects, you’ve got me. Otherwise, there’s a world of difference between an application with a mix of value objects/entities and an application with all value objects (ie.. not DDD).

As for tiering, in applications which exhibit this anti-pattern, you might only have two tiers, the asp.net and the data tier (the database server). Although sometimes you will also see it in three tiered architectures as well, where the application tier really surves no purpose than as a simple data conduit (ie..datasets through webservices). In fact, in these three tiered apps, it would often be more productive for the team to kill the application tier altogether. It typically serves very little purpose (other than just another thing for the team to work on). The logic is either in the UI (Smart UI Anti Pattern) or in the database (Web Database Anti Pattern).

I’m going through this transition now but I am faced with two problems:

1. I am proficient with T-SQL and can’t help but feel that many rules and queries are most efficiently implemented by the database.

2. What does an application “done right” look like?

Regards,

–
Jason

> An application with an anemic domain model has a high probability to exhibit this anti-pattern.

Is your point based on the fact that the behavioral context of the architecture are left outside of this tier and it is merely a representation of Data Elements? If so how do you explain pure DDD models that have Value objects that do not necessarily map to another table but require composition in their hydrated to anemic state within an Entity.

>But I would recommend starting down the road to growth ASAP.

Show us some refactoring bro!

You mean there are layers between the web and the database? No WAY!

Would this bring forth an argument about whether it is wise to turn on and use the CLR inside of SQL Server 2005?