现在。我想在控制器上作些手脚，就是。想在控制器引入动态工厂模式，即让请求以字符串的形式传给servlet，servlet通过Class.forName(String str)这个方法来动态加载bussiness业务逻辑类，这些业务逻辑类都实现了一个接口，从而可以让产生出来的业务逻辑类的对象可以赋给那个接口，以接口方法实现多态的调用业务逻辑类，但我觉得这种设计思想是不是削弱了控制器的功能而违背了MVC设计框架的初衷了？从而由MVC设计模式变成了MV模式了？控制器能否引入工厂模式呢？
控制器的功销饥能:该是读取xml配置文件然后进行view和model的映射的功能吧，你这个功能你没有切除吧。。只是你没有用这个功能而已！就是我觉得像这个应用应该只有一个servlet的，就是整个应用只有一个。。。而传统的是一个画面对应一个servlet，就是整个应用很多个servlet。
而空亏你这么一个唯一的servlet你也是通过命令模式再进行自定义的反射调用！！
所以我不觉得你‘违背了MVC设计框架的初衷’，你只是对control进行了具体调用时的自定义！确实有点像Dispatcher，如果你就做简单的调用的话！！我建议你做更多地处理！！比斗斗神如。。当你Class.forName(String str）之后是否可以考虑把实例保存下来！！不必每次都那样去invoke的！！！所以你还是MVC，而不是MV，你的C不但存在，而且以一种你希望的方式而存在！
当然可以，关键是你想对控制器进行怎样的自定义！！但是我敢说，仅仅引入工厂模式你的自定义控制器也太简单了点！
你这么做，实际上让Controller承担了Dispatcher的部分角色。而让Business Object承担了Controller的任务。
不过你可以参考Webwork2的实现，根据用户请求的Url Pattern和Method映射，反射调用同一个Action里不同的Method。这样可以将同一类的但意义不同的业务逻辑放在同一个Action的不同方法中。
你的设计思路实际是增强了 Controller，让它承担了不该承担的责任（业务请求祥基分发）实际上它已经成为一个微型的Dispatcher了。如果它拦截了全部的Request进行分发，那它跟Dispatcher本身没任何区别了。
另，任何类念册都可以引进Factory Pattern， 这个是结合具体情况看的。
至于你用Class.forName的方式，不反对，但是要知道，在Web应用中性能也很重要。有句话说的好：叫接口大于反仔宴宏射。
MVC 是个架构模式 与你的 动态工厂(应该是多态工厂吧) 可以春脊说是毫无关系！
你控制器怎么取得 模型粗森薯的 的实例！ 可以直接 new ,
可以 简单工厂，可以多态工厂 。岩者都无所谓。 都是 MVC 模式
写一个简单纳败的工厂念茄饥仔返
public abstract class ServiceFactory {
public static IEmpService getService () {
return new EmpService ();
}
}