竹篮打水一场空

我在昨天还坚定的认为我参与开发的项目架构是MVP+MVVM结合的，今天与同事交流一番，以及一些博客中的例子中更加混乱了，再把那两张结构图端上：

从图中可以知晓，无论是MVP还是MVVM都旨在将MV解耦，或者就是把二者分开不会相互影响，而且用到了Presenter和ViewModel来处理业务逻辑和一些UI改变的连接。

我仔细查阅我们项目中的Presenter和VM却发现Presenter和博客中的实例的确有类似作用，而且更加强大，因为，根据图中和许多博文中叙述的那样，它将Activity的复杂度简化了，但我们的项目却更加奇怪，因为我们基本上没有用到Activity。

对的，许多Activity文件甚至都只有一个反射Presenter的一个申明Presenter变量语句，我们的逻辑都在P层写，我们封装好的P层接口是类似于一个生命周期的仿写，不过更加方便，因为只有初始化数据，初始化V，V的改变事件监听以及数据改变的监听，数据改变的监听又可以用LiveData的observe去监听改变，而LiveData又能写在VM里，哈，我们的P层太伟大了，它一个人干了所有的事，不过不用去考虑activity的生命周期的确很开心，不过要用的话我们也有方法在p层调取重写，所以我同事说这个VM看起来更像是方便我们去看懂代码，以防写过长的P层，而且我们把VH和VM反射在p层，这更让我疑惑，MVP的目的，解耦到底在我们的项目有没有实现，更离谱的时，我看博客上MVP一般分三个接口，然后分别实现，还有一系列回调，而我们项目则没有明确的分开，但也并不感觉难写，反而感觉逻辑很清晰。

迷雾重重

所以，我们的项目究竟是什么架构，我仍得不出有效结论，因为他们都说到了接口的频繁调用回调让MVP和MVVM并不是很友好，而我在日常开发却没有这种体验，由此而引发了一系列对项目结构的疑惑。

那么，我们项目的结构到底是什么？不知道是否有属于它的名字？