> On 8/12/2006 Merlin Moncure <mmoncure@xxxxxxxxx> 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
