来源: 互联网  发布时间: 2014-02-18

移动开发中的领域模型

      最近在做保险行业的iPad客户端应用，在项目过程中引入了领域模型设计和MVC的设计思想，引发了一番争论。从实践过程来看领域建模更多的是一种分析和设计业务模型的一种方法。由于在ios开发中并没有像J2EE开发企业应用这样成熟的开发框架，MVC更多的应用在表现层的开发，UIViewController严格来划分应当都属于View（视图层），这也不怪苹果在ios上更多是针对小应用或者游戏的开发的精简版。

      个人认为不论在实际开发中是否引入领域模型层，都可以采用领域模型来分析业务，而在实际开发中领域模型层和J2EE现在广泛采用的Service层有相似之处。都是对业务逻辑的封装，Service层的引入来自于Controller层和贫血型模型层，由于随着业务逻辑的复杂度提升，Controller除了处理应用逻辑同时处理领域逻辑，造成Controller过重，从而将通用的业务逻辑提取出Service层作为封装和复用。贫血的模型从实际开发中更多是基于表的开发模式，从设计库表作为项目的核心，辅以业务流程图，最终实现为一个一个的Service。而领域建模从设计开始不关心数据存储和表现层，而是将业务模型抽象成一组相互协作的领域类，在类与类之间运用各种面向对象技术，使实际的业务映射成为类与类之间的关系。

      在我们的实际开发过程中，大部分的和数据相关的都不是数据库存储的，更多的是接口的调用。在系统中实现业务逻辑的方法有很多，常用的Service＋实体类起到了领域模型是起到同样的作用的，至于谁好谁坏，我觉得每个人的视角不同，做惯了J2EE的我想更容易接受Service＋实体类的模式。

      关于领域模型，100个人有101种领域模型，很难说谁的好谁的不好，只存在谁的好用谁的不好用。同时我们看到实际开发过程是一个除了代码，系统架构也在不断重构的过程。

      在客户端开发过程中使用领域驱动是否大材小用了呢？我觉得一个领域驱动是一种习惯，一旦掌握了就不太愿意采用其他的设计方法，即使它的业务逻辑很简单。第二，领域建模是一种设计方法，与具体的开发架构没有必然的联系，团队可以选择自己熟悉的开发框架来做。

        写的有些乱，全当给自己备案，有机会把实际项目中的设计总结一下。

    

    来源: 互联网  发布时间: 2014-02-18

andEngine游戏引擎介绍【原创】
AndEngine游戏引擎
近期学了好几天的AndEngine游戏引擎,在此稍微做个小总结.网上关于andEngine的中文资料是微乎其微,所以 更多的是你得去看英文文档和应有的自学能力作支撑.借此也想多和各位多多交流.
首先可以很肯定的说，AndEngine游戏引擎是比较适合自学游戏引擎的人士。我们可以很清晰的看到AndEngine的程序结构是采取按功能划分。分别为audio媒体处理、collision碰撞检测、engine游戏引擎，这个翻译有点抽象，其实engine包下主要是处理屏幕参数及UI异步刷新。
entity实体包，我们搞过web开发的童靴都知道，我们非常的喜欢entity实体对象，用于数据存储或者传输，这也是诞生DTO、DO的概念。而andEngine游戏引擎是把layer布局管理器、scene屏幕管理器、sprite游戏精灵、text文本信息、以及particle、primitive(这两个包偶目前还木有用到过。)
其中android也不缺乏屏幕触摸事件处理，这也摆脱android自带canvas的一堆繁琐操作。即在input.touch下就有一系列的触屏事件处理。其中部分也是采用了相关的单例设计模式优化。
同时游戏中关卡是不可避免的。而andEngine游戏引擎就有level包，此包下就是专门用于处理关卡的处理。
opengl包，我们一看名字就知道，此包是处理图像的。andEngine是2D游戏引擎，所以你不要抱有太多的3D效果幻想。opengl包下有font字体包、texture纹理包、view试图包、以及buffer、vertex在(这两个包偶目前还木有用到)。
sensor传感器包。android自带有很多的传感器，和游戏结合最为紧密的传感器莫过于重力传感器、自从疯狂地小鸟问世后，衍生了多少类“疯狂的小鸟”基于物理游戏引擎的游戏呢！但是andEngine下的传感器和android应用框架中的光线、辐射、重力、温度传感器又是有很多不同。毕竟游戏引擎的传感器是服务于游戏体验和游戏效果的。sensor主要是基于location位置传感、重力加速度、以及方位传感信息。
而ui包下面有dialog包和activity包。其实dialog包用不用都无所谓，因为android应用框架下的dialog是可以直接在andEngine框架下直接使用的。而activity包下就是andEngine对android传统的activity进行了一系列的封装。最终，如果你想创建一个activity，直接你的类去继承BaseGameActivity即可。不过，我们通常都不会直接继承BaseGameActivity，而是再自己创建一个系统公共类，去实现一系列公共方法。再由这个公共类去继承BaseGameActivity。
最后一个包是util包。此包涉及很大。其中有Base64的编码解析器，主要是用于TMX地图中的编码解释。借此也说一下andEngine游戏地图的制作。Tiled地图制作软件。
我们一般是采取Base64位gzip压缩方式。包括iphone上的一些游戏引擎例也是采用TMX游戏地图的。还有一些数学计算类、精灵路径类Path、SAX读取XML信息类SAXUitls、已经一些IO流文件操作。socket网络通信等等工具。

介绍完andEngine游戏引擎框架后，我们可以尝试去制作游戏。我们就会发现，如果直接采用andEngine传统的方式去制作游戏精灵游戏背景游戏文字，就会发现。
整个项目的架构是非常的凄凉。andengine有很多繁琐而又重复性的操作，所以我们应该采用OOP的方式，将整个andEngine进行二次封装。我们可以大大地简化我们的代码及项目管理难度。
而我目前也仅仅是将常用的UI游戏组件进行封装，例如游戏字体、游戏背景、游戏精灵统一进行封装。而将地图、游戏障碍物采用OOP的方式多态生成。至于后期的游戏制作，偶就不多说了，不同的开发团队的开发风格不一样。每个人项目经理的项目管理也不一样。
那些都是属于管理上的问题，偶就不多说了。
最后提一句，andEngine还是比较容易上手的。如果是初学者，可以下载相关的demo来学学。如果你找不到。就发邮件给我。xiaosimc@foxmail.com。以上信息仅供参考。望能多多交流

    

    来源: 互联网  发布时间: 2014-02-18

自定义 UITableViewCell 怎样在子控件触发时得到 indexPath
例如 每个UITableViewCell里有个UITextField，当UITextField获得焦点时不会触发tableview的didSelectRowAtIndexPath方法，就不能知道触发是哪个cell，下面方法可以获得UITextField所在行的indexPath，方法很简单，注意两种方式。

如果是将textField添加在cell.contentView上：

//获得row
NSInteger row = [[self.tableView indexPathForCell:(UITableViewCell *)[[sender superview] superview]] row];

//获得section
NSInteger row = [[self.tableView indexPathForCell:(UITableViewCell *)[[sender superview] superview]] section];

//获得indexPath
NSIndexPath *indexPath = [self.tableView indexPathForCell:(UITableViewCell *)[[sender superview] superview]];

如果是直接添加到cell上：

//获得row
NSInteger row = [[self.tableView indexPathForCell:(UITableViewCell *)[sender superview]] row];

//获得section
NSInteger section = [[self.tableView indexPathForCell:(UITableViewCell *)[sender superview]] section];

//获得indexPath
NSIndexPath *indexPath = [self.tableView indexPathForCell:(UITableViewCell *)[sender superview]];