与我们一起学习或学习过关系数据库的人是不同的.要获得期望的结果,并有效地实现这一点,需要一个乏味的过程,其部分特点是学习不熟悉的范例,并发现我们最熟悉的一些编程模式在这里不起作用.你见过(或自己犯过)哪些常见的反模式?
与我们一起学习或学习过关系数据库的人是不同的.要获得期望的结果,并有效地实现这一点,需要一个乏味的过程,其部分特点是学习不熟悉的范例,并发现我们最熟悉的一些编程模式在这里不起作用.你见过(或自己犯过)哪些常见的反模式?
我一直对大多数程序员在数据访问层混合UI逻辑的倾向感到失望:
SELECT
FirstName + ' ' + LastName as "Full Name",
case UserRole
when 2 then "Admin"
when 1 then "Moderator"
else "User"
end as "User's Role",
case SignedIn
when 0 then "Logged in"
else "Logged out"
end as "User signed in?",
Convert(varchar(100), LastSignOn, 101) as "Last Sign On",
DateDiff('d', LastSignOn, getDate()) as "Days since last sign on",
AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' +
City + ', ' + State + ' ' + Zip as "Address",
'XXX-XX-' + Substring(
Convert(varchar(9), SSN), 6, 4) as "Social Security #"
FROM Users
通常,程序员这样做是因为他们打算将数据集直接绑定到网格,而在服务器端使用SQL Server格式比在客户端使用SQL Server格式更方便.
如上所示的查询非常脆弱,因为它们将数据层与UI层紧密耦合.除此之外,这种编程风格彻底防止了存储过程的可重用性.