本人开发菜鸟，正在想改进自己的代码可读性，打算从SOLID和可测试性入手。
看到一篇文章：
http://www.cnblogs.com/wangiqngpei557/p/3280687.html
里面说到：
还有
在下面有这么一段代码：
/*==============================================================================
* Author:深度训练
* Create time: 2013-08-24
* Blog Address:http://www.cnblogs.com/wangiqngpei557/
* Author Description:特定领域软件工程实践；
*==============================================================================*/
namespace UnittestDemo
{
using System;
public class AppStart
{
public static void MainStart()
{
ReportAnalyse analyse = new ReportAnalyse();
bool result = analyse.Analyse(DateTime.Now);
if (result)
{
//
}
else
{
//
}
}
}
}
接着作者又说了：
为什么说这样的设计会违背单一原则，这段代码如何理解“在外部装载好”。
接着文章里面还出现了一个词DTO，查了下指Data Transfer Object，应该是是一个用于在方法之间传输不包含方法的纯数据结构。（不知道个人理解对不对哈）
根据以上获得的知识，于是我就YY到，BLL不直接调用DAL的方法获得数据，而是接受DTO，处理数据后返回。
那样的话，是UI调用DAL获得DTO然后再传给DLL吗？感觉也怪怪的，这样层级不是破坏了吗？
上网搜索了下，微软MVC模型把DAL和BLL和MODEL都封装在MODEL里了，届时找下MVC的源码来看下
以上都是我YY的，没有任何依据，求指正，也恳请大家谈谈自己的想法。
------解决思路----------------------
呵呵，如果不交互，你写啥代码。按那个理论“单一职责”就是不调用，那么分层干啥，直接在页面写sql，他就只负责自己，这就干净了
呵呵，“单一职责”不是不调用，而是自己只负责自己该负责滴，所以就真好解释你的问题，访问数据库不是BIL的职责，他是DAL职责，他们各自负责各自滴这正是“单一职责”啊，至于是DTO一类的跟这个问题毫无关联，那是两个独立职责系统的通讯协议而已。
这就好像，你公司的安排，你做你的事情，人家做人家的事情，需要配合的事情，由公司给你们派单，然后你们商量怎么配合。
------解决思路----------------------
职责这东西比较抽象的，横向与纵向的划分其领域（这词也有点装B）也不一样，注意划分，这是指模块的粒度。经典的三层架构，是把软件体系抽象成数据层、业务层、表现层，做开发的负责各模块的人员根本不需要关注其它层，各司其责，但又会按照一定的约定，为什么，因为每个层次只需要做好自己的职责就行了。那为什么要这样划分，这是软件发展的其中一个进程结果，前辈的经验。如果我不这么搞，直接一个UI，然后后端写db和逻辑不就完事了，这样是完全妥的，而且很多人会说快捷，搞那么多干嘛（很多私单的人没太多设计的概念，人家要的就是效率，能做出来就行了，管它那么多），那为什么我们不这么做，这就是耦合一词的精髓了，软件工程强调的其中一个概念就是“高内聚，低耦合”，你可以把整个的工程代码想象成一个机器人（大片动漫的那种，小时候我们看的经典的《战神金刚》[5个老虎组合的]），如何方便的组装和拆分这成了很重要的设计课题，同一个机器你拆成的零件不一样，每个零件的职责领域也是不一样的，但是要尽可能的保持各自功能的单体特征，各个功能间的交流需要按照特定的约束条件。
讲的有些虚，还是老话，功到自然成，多看吧！
------解决思路----------------------
简单来说，有点拗口的所谓“单一职责原则”就是用来力挺继承和多态机制的，只不过它使用了“釜底抽薪”的办法来反对“胡乱组合”，而不是直接反对组合。
实际上你真正有那个需求时才应该讲求技术，不可过早地强调理论化，不可仅仅是“死扣字眼”而夸大任何模式。所以真正的技术是体现在“蜕变”过程中的应用技术，而不是体现在一开始“高大上”地所谓架构。如果抬高了人员成本、设计成本、维护成本，而你的产品在半年内根本用不上什么抽象的DAL层，你为什么不在BLL中直接调用你现成的DAL层呢？
------解决思路----------------------
再强调一大堆很高级的抽象概念的同时，我们要强调编程人员的“本质”还是要追求“尽量少设计class/interface，尽量少抽象，尽量少写代码”的。不可变成一个拼命发明雷人技术名词儿的匠人，要做一个实践者。
------解决思路----------------------
人家YY,你也跟着YY,
如果学校里面没有开设OOAD这门课程,那就自己找本OOAD的教材好好学学