和其他很多概念一样，我虽然是知道它们的存在，但是在写代码的时候，仍然是糊里糊涂，很多时候，我都不知道为什么这段代码要这么写？似乎写代码的思路是在跟着业务流走，业务流怎么执行，我就怎么写，这便是我的第一判断。至于那些设计模式和层的概念，早就被抛在脑后了。这是我的烦恼。
今天，有一段代码，在同事的提示下，我对DAL的理解又有了新的理解。这实际上是一个bug，呵呵：
//这个方法就是DAL里面的方法
private void UpdateLog(long logID, string title, string Initials, ...)
{
//这个方法在执行的时候，实际上没有对Initials字段进行更新操作，这就是bug；
}
当我把这个方法报告给我的同事的时候，我的建议是从参数列表中去掉Initials，原因很简单，因为在业务逻辑中规定，Initials数据一旦创建不能被更改。但是我的同事立即决定在这个方法中加上对Initials字段的赋值，他说客户端在处理Initials的时候，已经限制了对Initials数据的编辑。
后来我思考了一下，他的这个做法是完全正确的。因为这个方法是数据处理层中的方法，它要做的只是处理数据。但是后来我又思考了一下，仅仅做出这样的结论是没有意义的。因为我的判断的结果也是在处理数据。所以后来我又添加了一个条件：DAL中，不要包含业务逻辑，比如，我刚才的那个判断就把对业务逻辑的放进去了。
我觉得我们之所以要把各种逻辑分开，除了我们涉及的系统越来越复杂之外，还有很多技术可以支持数据的攫取。在这里，我之所以用“攫取“一词，是因为目在DAL一层的框架有很多，比如hibernate,subsonic等等。我觉得他们的出现，实际上只有一个目的，就是让业务逻辑和数据库之间的gap越来越小。
不过对于我自己来说，还有很长的路要走呀！