我正在尝试更多地了解MVC。到目前为止,我对较小的程序做得很好。出于我的目的,我一直在我的模型中保留所有业务逻辑和“结果”。目前我有4个类,我的主类,视图类以及模型和控制器类。
我现在正在考虑将一些业务逻辑与我的模型类分离并将其放在一个单独的类中。这是我不确定最佳做法的地方。我应该在我的模型类中创建/引用我的新类,还是应该直接从我的控制器类中创建它。
我不确定它是否有用,但这是我目前的控制器类:
public class BrowseController {
private BrowseModel m_model;
private BrowseView m_view;
public BrowseController(BrowseModel model, BrowseView view) {
m_model = model;
m_view = view;
view.addRunListener(new RunListener());
view.addClearListener(new ClearListener());
}
class RunListener implements ActionListener{
public void actionPerformed(ActionEvent e){
start();
}
}
class ClearListener implements ActionListener{
public void actionPerformed(ActionEvent e){
System.out.println("clear");
m_view.reset();
m_model.reset();
}
}
private void start(){
SwingWorker<Void, Object[]> worker = new SwingWorker<Void, Object[]>(){
@Override
protected Void doInBackground() throws Exception {
m_view.setStatus("Running");
HashSet<String> urls = m_view.getTargetUrls();
for (String url : urls){
m_model.processUrl(url);
publish(m_model.getResults());
}
return null;
}
@Override
protected void done() {
m_view.setStatus(m_model.getStatus());
}
@Override
protected void process(List<Object[]> resultList) {
for(Object[] resultRow : resultList){
m_view.setResult(resultRow);
}
}
};
worker.execute();
}
}
如果还有什么我应该提供的,请告诉我,谢谢。
答案 0 :(得分:0)
据我所知,如果它是纯数据业务对象,您可以将它添加到您的模型中。 如果您正在考虑对数据进行一些处理,那么我更愿意将其添加到控制器中。
这只是我的观点;让我们看看另一个想法。
答案 1 :(得分:0)
我会尝试给你一个答案(因此我无法告诉你最佳实践的例子......如果你提供剩下的资源,即使我不是软件工程师而不是软件建筑师)指出在这里发挥作用的一些想法/主题。因此,请注意关键字,您阅读/了解的越多,您成为软件架构师的次数就越多,并且可以通过指向相应的信息来源来回答这些问题并进行证明。
首先,我同意User neoboard关于业务对象(代表要在视图中显示的数据)属于MVC模型的模型部分(我仍然没有读过 Trygve Reenskaug的作品强>也不是来自四人帮[Gof] )。当你的业务逻辑变得像我记得的那样,在MVC模型中没有规范在哪里放置它(由于模型是一般的语言,并且它的具体实现因语言而异)但最常见的是它被考虑驻留在Java等高级语言的控制器部分。
说到MVC,我记得从学校/学习时代开始,这个设计模式的重点在于让模型和视图部分尽可能地彼此分离(标准学校样本“因此您可以在不对模型进行任何更改的情况下交换视图”)。要将其提升到更高级别,可以说您希望归档对象的松耦合,以使其尽可能重用。
现在,即使您在源代码中某处遵循观察者等模式,您也必须将线路放在一起(控制器部分),特别是作为初学者,看到不同模式之间的一些冲突(这与我一样谨慎)知道永远无法彻底解决)。
有关联和合成的概念,当与抽象和专业化和语言功能混合使用时比如接口和抽象类(Java)允许您拥有非常通用的代码,其中理论上非常容易地交换不同的组件。
现在这就是我希望你从理论部分讲述的内容(更好地看一本好书以确保你获得有效的信息)。
另一部分是它在实践中的表现。在Java EE中我工作的例子松散耦合最终主要由依赖注入归档,其中一个类只保存接口类型的引用并在EE运行时获取实现对象实例容器(Websphere,JBoss,Glassfish等)。此外,大型设计模式通常不是自动连接,而是通过使用框架来实施,这些框架应该强制执行和/或支持最佳实践和设计模式,仅提及有关其如何完成的几个部分。理论结束。
仍然是一些非常甜蜜的理论,但是我可以告诉你甚至瑞士的银行系统都很难维护,因为像我这样的软件工程师已经做了很多架构部分和架构这些天经常不知道来自在管理人员根本不知情的情况下,工程部分并没有看到“浪费”设计上的钱那么多(开始改变但是进程缓慢......)。
如果你刚刚开始学习Java(“开始”......我关心MVC就像2年后的Java一样)不要害怕以错误的方式做事情,但要尽量与少数人保持联系一家公司可以指出错误的部分,并解释如何做得更好(而且不仅仅是高兴它便宜并且运行正常)。
当有一天在大型项目上工作时,不仅要完成任务,还要理解为什么某些东西按照它的方式构建(如果你有时间的话,没有更好的东西),即使它遵循模式,也可以让自己询问是否它真的让你的软件工程师更轻松。
我现在拥有大约13年的Java经验,曾在金融,公共交通和军火行业工作,他们拥有真正重要的Java EE应用程序......他们都不需要像我这样的软件工程师如果这些概念很容易应用,或者有一种简单的方法可以验证它在某种尺寸/复杂性方面是否以正确的方式完成。
我希望我可以用另一种方式帮助你,而不是直接在你当前的源代码级别上,你可以让我看到许多拼写错误(瑞士德语是我的母语......我们甚至没有官方语法。 ..)。保持良好的工作!