C# C/S MVP模式求指导

[xiaoqiang5448]

需要完成的项目是C/S的，通过以太网通信获取数据，并且显示到UI，采样频率为20MB/s，所以数据量是比较大，基本情况就是这样，现在刚刚开始，想请教一下软件设计上的问题。
一开始，我的程序就一个类，不是我不想分分层，而是那个时候没啥经验，然后看到项目小，很简单的，就那么做了，做完之后发现代码很混乱，修改起来很麻烦。
后来的项目么也就开始分分类了，把数据处理放在一个类一里面，然后通过注册事件来显示数据，类方法用public，在UI中直接通过类对象来调用方法，这样做比起之前的一个程序一个类的做法当然好了点，至少结构清晰了一点。
后来再做项目，发现其实数据处理逻辑跟UI逻辑老是搞混在一起，然后项目进行过程中，UI需要改动，或者逻辑上需要一些调整的时候，要花很大的力气去修改，诶，所以，想学学MVP的设计模式，不是之前不知道有这个模式，只是有时候没考虑那么多，恰好新项目，我想好好的，好好的按照设计设计再做编程。
现在的问题是，我很难把UI逻辑跟业务逻辑区分开来，实际的开发过程中，总是在UI中夹杂很多数据处理的东西，然后在设计上很明显Presenter跟View交互的太多了，只是简单实用注册事件-委托显示的方式来做，效率很低不说，其实我不懂如何避免P跟V的直接调用。
看到一篇博客，很好，但是感觉还是不太理解。http://www.cnblogs.com/artech/archive/2010/03/25/1696205.html

[xiaoqiang5448]

三、理想与现实的距离

上面对Passive View MVP特征的罗列，我觉得是一种理想状态。是在大型项目中，尤其是项目的开发者自身并不完全理解MVP原理的情况下，要整体实现这样的一种理想状态是一件很难的事情。有人可能会说，在开发人员不了解MVP的情况下要求他们用好MVP，你这不是扯淡吗？实际上，在这里并不是说开发人员完全没有MVP关于关注点分离的概念，只是对MVP中的三元角色并没有非常清晰的界定（实际上也没有一个明确的规范对Model、View和Presenter具体的职责范围进行明确的划分），在开发的时候，会不自觉地受传统编程习惯的影响，将Presenter单纯地当成是View调用Model的中介。我经常这么说：如果以View为中心，将Presenter当成是View和Model的中间人，这也叫MVP模式，不过这里的P不是Presenter，而是Proxy，是Model在View的代理而已。

从Passive View中Model、View和Presenter三者之间的依赖关系来看，这个模型充分地给了开发者犯这样错误的机会。注意上面的图中View到Presenter的箭头表明View是可以任意的调用Presenter的。开发人员完全有可能将大部分UI处理逻辑写在View中，而Presenter仅仅对Model响应操作的简单调用。因为在我Review的各种所谓的MVP编程方式中，有不少是这么写的。在很多情况下，甚至不用认真去分析具体的代码，从View和Presenter中代码的行数就可以看出来，因为View的代码和Presenter的代码都不在一个数量级。

我现在的一个目的是提出一种编程模式，杜绝开发人员将程序写成基于Proxy的MVP，在我看来，唯一的办法就是尽量弱化（不可能剔除）View对Presenter的依赖。实际上，对于MVP来说，View仅仅向Presenter递交用户交互请求，仅此而已。如果我们将View对Presenter的这点依赖关系实现在框架层次中，最终开发人员的编程来说就不需要这种依赖了。那么我就可以通过一定的编程技巧使View根本无法访问Presenter，从而避免Presenter成为Proxy的可能的。

那么，如果在不能获得Presenter的情况下，使View能够正常将请求递交给Presenter呢？很简单，通过事件订阅机制就可以了，虽然View不可以获取到Presenter，但是Presenter却可以获取到View，让Presenter订阅View的相关事件就可以的。

[idea_yuye]

我于楼主有着一样的苦恼，在实际的编程实践中，很难去区分UI层和逻辑成。往往让我狠苦恼。网上说的一些实现MVP模式的例子很难在实践中应用，感觉像是一个理想状态，对于mvp的初学者来说，根本无从下手。