常见问题

C# 定论：

1) 循环中的值就是迭代元素,通常不容许在迭代即循环时被修改，必须经过临时变量作转换

2) 方法参数不能在该方法中被修改，必须经过临时变量作转换

3) 类的公共属性或字段不能在类中被修改

 

来源路径：http://bbs.csdn.net/topics/392164212

• 如何统计APP在线时长（容许有必定的偏差），怎样判断用户是否还在线

　　　　在全局应用程序类Global.cs中找到SessionStart开始事件和SessionEnd结束事件　　　

　　　　在Session开始事件中定义Session保存登陆时间和登陆状态State,而后在Session结束事件中得到登出时间，而且清除登陆状态，

　　　　经过2个时间相减得到在线时长.经过登陆状态判断用户是否在线

• 数据库表中有一字段表示类型，不知道这个类型会有多少种，查出每一个类型插入的最新一条数据

select * from(
    select  
    *,　row_number() over(partition by Type order by id(主键) desc) rIndex 
    from 表名
) vw where vw.rIndex=1

• 谈谈你对websocket、webapi的理解

　　WebSocket是基于TCP网络协议。服务器主动发送信息给客户端.

　　WebSocket原理:

　　在实现websocket连线过程当中，须要经过浏览器发出websocket连线请求，而后服务器发出回应，这个过程一般称为“握手” (handshaking)。在 WebSocket API，浏览器和服务器只须要作一个握手的动做，而后，浏览器和服务器之间就造成了一条快速通道。二者之间就直接能够数据互相传送.

　　服务器的推送，服务器再也不被动的接收到浏览器的request以后才返回数据，而是在有新数据时就主动推送给浏览器。

　　Web API是构建REST服务的平台,它支持MVC路由等功能，控制器，做用结果，滤波，模型绑定器，IOC容器和依赖注入，单元测试

• 支付宝支付，微信支付，银联支付
  • 支付宝　

1. 1. 提交支付请求到支付宝获取支付宝POST过来通知消息，并以“参数名=参数值”的形式组成数组 
      1. 若是已经支付过则跳转到首页
      2. 查找没有支付的订单
      3. 支付类型,1为商品购买
      4. 服务器异步通知页面路径，需http://格式的完整路径，不能加?id=123这类自定义参数
      5. 页面跳转同步通知页面路径,需http://格式的完整路径，不能加?id=123这类自定义参数，不能写成http://localhost/
      6. 商户订单号,商户网站订单系统中惟一订单号，必填
      7. 订单名称,必填
      8. 付款金额,必填
      9. 防钓鱼时间戳,若要使用请调用类文件submit中的query_timestamp函数
      10. 客户端的IP地址,非局域网的外网IP地址，如：221.0.0.1
      11. 把请求参数打包成数组
      12. 创建请求
   3. 解读支付宝接口实现步骤
   4. 支付宝实现主要步骤：

　　　　　　　由两部分组成，接入部分与通知返回部分。

　　　　　　　接入部分即为传递参数等信息组合成超级连接，并用该连接来进行跳转。　　　　

　　　　　　　通知返回部分则是支付宝服务器对该笔订单处理完毕后，通知与返回该笔订单的详细信息到商户服务器，商户服务器接收到后，并对其进行数据处理。

• • • • 接入部分原理
        • 选定参数信息
        • 排序
        • 加密
        • 拼接字符串成URL连接
        • 自动跳转
      • 通知返回部分原理
        • 验证是不是支付宝服务器发来的请求
        • 排序
        • 加密
        • 判断
        • 自身网站的数据处理
  • 微信支付
    • 参考路径:
      
      • http://blog.csdn.net/qq_31927865/article/details/52605296
      • http://www.cnblogs.com/wuhuacong/p/5390468.html
      • https://my.oschina.net/bigfool007139/blog/598431
    • 支付流程
      • 获取订单信息
      • 根据订单信息和支付相关的帐号生成sign，而且生成支付参数
      • 将支付参数信息POST到微信服务器，获取返回信息
      • 根据返回信息生成相应的支付代码（微信内部）或是支付二维码（非微信内），完成支付。
    • 开发步骤
      • 客户端代码获得用户购买的商品信息，将之传给本身公司app服务器
      • app服务器调用微信“统一下单”接口，获得prePayId订单号并返回prePayId给手机客户端；
      • 手机客户端使用prePayId及商品信息调起微信客户端进行支付；微信客户端回调支付结果给我们的APP客户端； 
        • 用户操做：输入密码进行支付；返回键取消支付；网络无链接支付失败等； 
      • 微信服务器异步通知我们公司app服务器支付结果（服务器的工做，与客户端无关）
  • 银联支付
    • 参考路径：http://blog.csdn.net/chen504390172/article/details/16962905
    • 持卡人浏览商户网站，选择支付项目，生成订单信息

    • 持卡人确认订单信息，开始支付

    • 持卡人确认支付信息，商户网站开始向支付网关申请支付，支付网关验证商户身份合法性和订单报文的完整性

    • 支付网关向持卡人显示支付渠道选择界面，持卡人选择支付渠道

    • 持卡人在所选择渠道上，输入用户账号、密码及其余安全验证信息 

    • 持卡人的安全认证信息获得确认后，进行支付

    • 支付渠道向支付网关返回支付结果

    • 支付网关向持卡人显示支付结果，同时通知商户网站支付结果

    • 商户网站向持卡人显示商户交易结果 

    • 支付操做完成。

• 若是让你为APP提供数据接口，你会注意什么问题
• 参考路径：http://blog.csdn.net/junli_chen/article/details/51180797
• 跨平台性 
• 良好的响应速度 
• 接口要为移动客户端考虑 
• 考虑移动端的网络状况和耗电量 
• 通用的数据交换格式 
• 接口统计功能 
• 客户端与服务端的肥瘦平衡
• 隐式用户与显式用户 
• 安全问题  
• 良好的接口说明文档和测试程序
• 版本的维护
• 在APP中，定位附近模块的数据你是如何提供的。假如A从当前位置(A1)向前移动了100/200/300米到了（A2）位置，A2位置商家信息，是如何到得的。
  • 基于百度LBS云服务提供了数据接口
  • APP中根据定位实现搜索附近（POI）的功能，采用百度LBS云服务，将全部POI数据上传后，能够实现该功能。
  • http://www.cnblogs.com/licin/p/6809603.html提供了获取移动app的坐标，而后获取商户坐标，根据2个坐标计算得到距离和位置。
• 大数据 并发
  • 参考路径：http://blog.csdn.net/buynider/article/details/8655804
  • 常见状况

    • 大量的用户同时对系统的不一样功能页面进行查找，更新操做

    • 大量的用户同时对系统的同一个页面，同一个表的大数据量进行查询操做

    • 大量的用户同时对系统的同一个页面，同一个表进行更新操做

  • 第1种状况通常处理方法
    
    • 对服务器层面的处理
    1. 调整IIS 7应用程序池队列长度
    2. 调整IIS 7的appConcurrentRequestLimit设置
    3. 调整machine.config中的processModel>requestQueueLimit的设置
    4. 修改注册表，调整IIS 7支持的同时TCPIP链接数
    • 对数据库层面的处理
    1. 什么都不作 –若是并发用户修改的是同一条记录，让最后提交的结果生效（默认的行为）
    2. 开放式并发（Optimistic Concurrency） - 假定并发冲突只是偶尔发生，绝大多数的时候并不会出现； 那么，当发生一个冲突时，仅仅简单的告知用户，他所做的更改不能保存，由于别的用户已经修改了同一条记录
    3. 保守式并发（Pessimistic Concurrency） – 假定并发冲突常常发生，而且用户不能容忍被告知本身的修改不能保存是因为别人的并发行为；那么，当一个用户开始编辑一条记录，锁定该记录，从而防止其余用户编辑或删除该记录，直到他完成并提交本身的更改
    4. 当多个用户试图同时修改数据时，须要创建控制机制来防止一个用户的修改对同时操做的其余用户所做的修改产生不利的影响。处理这种状况的系统叫作“并发控制”。

 

• • • 管理数据库中的并发有三种常见的方法：

• • • • 保守式并发控制 - 在从获取记录直到记录在数据库中更新的这段时间内，该行对用户不可用。
      • 开放式并发控制 - 只有当实际更新数据时，该行才对其余用户不可用。更新将在数据库中检查该行并肯定是否进行了任何更改。若是试图更新已更改的记录，则将致使并发冲突。
      • 最后的更新生效 - 只有当实际更新数据时，该行才对其余用户不可用。可是，不会将更新与初始记录进行比较；而只是写出记录，这可能就改写了自上次刷新记录后其余用户所进行的更改。
  • 第2种状况通常处理方法
    • 对表按查询条件创建索引
    • 对查询语句进行优化
    • 能够考虑对查询数据使用缓存
  • 第3种状况通常处理方法　
    • 先将数据保存到缓存中，当数据达到必定的数量后，再更新到数据库中
    • 将表按索引划分(分表，分区)，如：对于一个存储全国人民信息的表，这个数据量是很大的，若是按省划分为多个表，在将全国的人民信息按省存储到相应的表中，而后根据省份对相应的并进行查询和更新，这样大并发和大数据量的问题就会减少不少

 

 

• 7.68转int是多少
  • 8
• EF的优缺点
  • 参考路径：http://www.cnblogs.com/wintersun/archive/2013/03/16/2963992.html
  • 优势：

1. 1. 框架的类映射表，须要编写映射代码, 而且是很难维护的。 
   2. 可维护性，易于理解的代码，无需创造大的数据访问层。 
   3. 提供LINQ查询数据库，这须要从初级开发人员不太了解SQL。 
   4. EF能够用做用于数据服务和OData Service的基础设施。
   • 缺点：
   1. 实时的应用程序不利于EF同步。 
   2. 只能经过存储过程访问数据库。 EF的优点是：跟踪实体状态Change时，不只仅在存储过程上.（即便EF确实对存储过程支持有限的）。 
   3. 频繁插入操做（Insert）,  而且EF不支持大数据Bulk 插入。 
   4. 频繁更新操做，更新的目标主要是当多行（用一个单值） 
   • • 例如：UPDATE 表名 SET ColumA = 10 Where ColumnB =？ 
   1. 这种更新操做更好的使用的ExecuteNonQuery（也可从Context上下文或直接从Ado.Net）。 
   2. 反范式的表设计和高性能查询。 EF产生查询，他们是难以维护的，它并不能很好地支持映射到不规范的表。
   3. 对程序有很是的性能要求, 须要对每一个查询进行监控.