> On 8/12/2006 Merlin Moncure <mmoncure@gmail.com> wrote:
> the .net 'way' of database application development is to keep
> all the logic in the .net middleware. please note that I am
> completely opposed to this because it obfuscates good data
> management practices. however based on the op's comments I am
> guessing he is doing things the .net way.
>
> merlin
Speaking as an architect on both Java-based systems and .NET-based
systems, I need to jump in and correct this before too many rumors get
started. The .NET camp argues about this all the time in the same way
that the Java camp does: should the business logic be in the database
tier or the middle tier, with valid arguments on both sides depending on
the specific situation. (I tend to lean heavily towards database tier
myself for most data-related tasks, although in some cases this is more
for the benefit of performance than for design.) Plus the .NET camp has
the same problem with less-advanced developers embedding business and
database logic in the _client_ tier as does the Java camp (the .NET
folks embed their dynamic SQL in Winforms apps and ASP/ASP.NET code
while the Java folks embed theirs in Swing apps or JSP).
The argument seems to be raised again more often now in the .NET camp
since the release of SQL Server 2005, since SQL Server 2005 can run CLR
(.NET-based) procedures native inside the database. Now, of course,
some of the people who were keeping their .NET code in the middle tier
are starting to move this code into the data tier (still running their
same .NET code, but now running inside the database process space).
Whether or not in fact this is the right layer for that specific
operation depends on the situation.
- Bill
