Re: Another option for keeping application tiers independent

[jehugaleahsa]

On Jun 13, 3:09*pm, "Bob Powell [MVP]" <[e-mail]>
wrote:

I think this is possibly the longest post I've ever seen on this group.
I will try to be brief in my response.

I apologize for the size. I should have probably put this on a blog or
something.

>
Dependencies within any architecture are inevitable. How those dependencies
affect the physical structure of the application is important. Detailed
information on levelization of an architecture, the mastering of the
physical rather than the logical structure of the application can be
obtained easily in a .Net context using nDepend.

I'm not interested in tools. I interested in concepts / better ways of
handling day-to-day design decisions.

>
Your point about authentication seems to be confused and I don't see how it
might change the way your dependencies work. The role or rights of the user
may be specific but unless your architecture is lousy that shouldn't make
the application more monolithic.

The point with authentication was that there is no such thing as a
perfect separation between the user interface and the data tier. With
that unavoidable fact, it really doesn't make sense for there to be a
tier in the middle that, more than likely, also needs to be aware of
the data tier. This huge post was really identifying that single fact
and finding ways of eliminating unnecessary dependencies. I never said
the solution proposed should be accepted by anyone; I just thought
someone might find a different approach to system architecture useful.
The folks in my shop did. I would recommend reading "Patterns of
Enterprise Architecture" by Martin Fowler. He touches on the common
problem of keeping tiers separated. In many shops, the solidity of a
system takes months to be realized. Furthermore, keeping things
independent increases the ease of testing. I am kind of questioning
the viability of a layered architecture as is found in many newer
applications. There is a strong assumption by developers that an
application will always stay within the boundaries of a DLL. The
architecture I presented eliminated some of these issues . . . but
obviously came with problems of its own . . .

This article had nothing to do with the size of the application. I
have successfully implemented a few applications with this
architecture. It turned out to be a very useful architecture for
maximizing code reuse. In fact, by cutting a few corners, I was able
to implement these applications with about the same amount of code as
any other architecture. I kind took the goals of the architecture to a
higher degree than necessary. My goal in doing that was to show that
complete independence can be achieved.

>
I think that you are describing a need for a service oriented architecture
in which the authentication plays a primary role.

Not a primary role. Not even close! The problem is that even a single
log on screen can impact the entire application if the architecture
isn't carefully chosen. Most layered architectures rely on a static
data source. Some risk can be mitigated by hiding the data source
behind the data tier. However, this will not be 100% possible. 99% of
the time in single-point applications, this probably doesn't even
matter. However, in multi-point architectures, assuming one data
source can totally ruin a system. Even switching between on database
vendor to another can be a massive change, since the authentication
method may change.

>
I work in a very secure environment; a bank. We have to deal with
authentication and data oriented architectures all the time and we pay
careful attention to the way we build our applications. We certainly don't
have the sort of problems you seems to complain of and we deal with trades
of millions of dollars per day.

The size of the application is inconsequential. Your bank probably has
a very specific way of authenticating and a very specific type of
storage. It is probably okay for your shop to assume Oracle or SQL
Server. How aware is your user interface of the database? How aware of
the databases are your business processes? How much of the business
logic is repeated across applications? How well could your software
handle switching between Oracle and SQL Server . . . XML documents?

All I am saying is that it is almost impossible for a change in the
data tier to affect only the data tier. The reality is that it will
undoubtably affect the user interface. If you are using a layered
architecture, it is also likely that it will affect the domain layer.
How do you minimize the impact?

--
--
Bob Powell [MVP]