不用盲目追求面向对象，面向对象适合很多现实逻辑，但不代表适合所有逻辑
很明显，你用了类，你用了对象，你用的东西是面向对象的，但你自己写的东西是面向过程的
用组合模式封装，将DataInfo与BLL.Data与DAL.Data集成，形成一个逻辑处理类，但感觉与MVC模式背离
很明显，你用了类，你用了对象，你用的东西是面向对象的，但你自己写的东西是面向过程的
用组合模式封装，将DataInfo与BLL.Data与DAL.Data集成，形成一个逻辑处理类，但感觉与MVC模式背离
调试欢乐多
1、数据库的设计，既然是数据库，他的设计方法就和面向对象设计相背离的。
2、petshop把一些数据表映射成了实体类，其实这也只是考虑了业务逻辑而已。
3、并不是说有了强类型、泛型集合、DBHelper.cs、UserInfo、BLL.User就是面向对象的，没有了就不是面向对象的，面向对象是一种思想，不是流程。面向对象包括面向对象的设计，面向对象的编码。
4、分层！=面向对象。
是应该好好的学学！
定义3个变量，a=长，b=宽，c=a*b
而面向对象的思路：
先创建一个长方形的类，在类里定义两个属性分别为长、宽，再定义一个面积方法
然后实例化这个类
举个例子来说吧，你要在网站增加个log功能，如果你是已面向过程的想法可能就是这样public class Log
{
public void Write(string loginfo)
{
//具体的实现,假如说是写入到数据库中
}
}然后你就在各个需要用到log功能的地方增加
Log log = new Log();
log.Write("信息1");
你看看，这段代码中有class吧，也解决了实际的问题了，但你这就是面向对象了吗？
这时候项目要求变化了，要将原来要存入数据库中改为存入文件中，你就会发现需要修改代码了，不过简单！将Log中的Write修改一下就可以了。
接着项目需求又变了，Log有的地方要存到数据库中，有的地方要存入文件中，又要改代码了，怎么改呢，像这样改？public class Log
{
public void WriteDataBase(string loginfo)
{
//具体的实现,假如说是写入到数据库中
}
public void WriteFile(string loginfo)
{
//具体的实现,假如说是写入文件中
}
}你会发现噩梦来了，你需要修改散落在项目中成千上万个调用的代码，即使你修改好了，那以后呢？需求又变化了呢？
你会想为什么会出现这样的问题，我不是也使用了对象了吗？甚至我的项目也使用到了分层了呀？难道不是面向对象吗？
没错，你是使用了这些时髦的技术，什么反射啊，分层啊，封装、继承、多态你都很熟悉，但你的思路仍然处在面向过程之中，你只是以面向过程的思路来解决问题而已
OO设计要遵循5大原则：
1、开闭原则(OCP);
2、里氏替换原则(LSP);
3、单一职责原则(SRP)；
4、依赖关系倒置原则(DIP)；
5、接口隔离原则(ISP)
这些网上大把的文章来说明，
如果需求一直在改，项目有可能会做死，这就是为什么项目成功率不高的原因，主要原因就是客户需求不断变化，而设计人员设计的系统不足以承受这种变化。//
开闭原则说，不能直接在具体类上修改，但可以继承抽象类或实现接口，但是继承抽象类或实现接口不也是要添加代码吗，如果需求无止境的改变，那我不是要无止境的继承，无止境的实现接口？
//开闭原则不是说不添加代码，而是不对以前的代码再做修改，在已有的类和接口上实现。
如果需求无止境的改变，那么你只需要实现必要的接口或者继承抽象类。至于说需求一直改变，甚至改变到和原来的项目一丝边都不挨的时候，恭喜你，你的项目失败了，重新设计，因为这是另外一个项目了。楼上机会说的需求改变，开闭原则都是在一个产品可以改变的范围内，比如工资计算方式变了，比如什么什么的，而你忽然增加了N个风牛马不相及的东西，能一样吗？
面向对象并不是解决问题的唯一方法，而且在很多情况下也并不是最好的方法。
万物变化，自有其特点，想一切都OO，那就会over。
这些为面向对象而设计的语言都少不了“自己”这个概念
当然“自己”也是要被抽象的，所以也都少不了“class”
思考问题的方法不限于某个领域更不限于某种语言，哪怕是用汇编也能实现面向对象的开发。
所谓的类，顾名思义就可以知道是个抽象的概念
一定要弄明白多态的概念，真能真正理解OO
而封装与继承只要智商不是太低很容易理解~
建议看书《C# OBJECT从概念到代码》