一.MFC对多线程编程的支持 MFC中有两类线程,分别称之为工作者线程和用户界面线程.二者的主要区别在于工作者线程没有消息循环,而用户界面线程有自己的消息队列和消息循环. 工作者线程没有消息机制,通常用来执行后台计算和维护任务,如冗长的计算过程,打印机的后台打印等.用户界面线程一般用于处理独立于其他线程执行之外的用户输入,响应用户及系统所产生的事件和消息等.但对于Win32的API编程而言,这两种线程是没有区别的,它们都只需线程的启动地址即可启动线程来执行任务. 在MFC中,一般用全局函数Afx

CWnd* h_q = AfxGetApp()->GetMainWnd(); //获取主窗口的句柄

CWnd* h_d2 = AfxGetApp()->GetMainWnd(); //获取主窗口的句柄 h_d2-> GetDlgItem(IDC_EDIT2)->GetWindowText(strSend); //IDC_APOETRY_EDIT为编辑框的ID

在一次请求中,即一个线程内,若是用到EF数据上下文对象,就创建一个,这也加是很多人的代码中习惯在使用上下文对象时,习惯将对象建立在using中,也是为了尽早释放上下文对象, 但是如果有一个业务逻辑调用了多个dal层的方法,交互数据库多次,这样效率会低一些,而且在使用EF的情况下,我们通常把SaveChange这个方法提到业务逻辑层(下文中会提到),不保证同一个业务逻辑使用的是同一个上下文对象,事务,工作单元模式将无法实现.而且可能造成数据混乱,每次创建的对象执行相应的数据库操作,与此同时,同一次

1.ef添加完这个对象,就会自动返回这个对象数据库的内容,比如下面这个表是自增ID 最后打印出来的ID  就是自增的结果 2.lambda 中怎么select * var userInfoList = from u in db.UserInfo select u; 3.返回类型 IQueryable<T> 它继承 IEnumerable<T> 相当于集合 延迟加载机制  用到的时候才去数据库查 4.两种删除标记 db.UserInfo.Remove(userInfo); db.En

说到线程内唯一,肯定会想到单例模式,但是如果多用户访问网站就会出现问题.ASP.net中有两种方法可以保证EF操作类线程内唯一(目前只会这两种,以后有好的方法再添加): 1.httpcontext(实现原理也是通过数据槽callcontext) 将EF操作类通过键值对方法保存在HttpContext.Current.Items["key"],封装成方法直接调用 2.callcontext public static DbContext CreateDbContext() { DbCon

如果说,一个对象保证全局唯一,大家肯定会想到一个经典的设计模式:单例模式,如果要使用的对象必须是线程内唯一的呢? 数据槽:CallContext,ok看下msdn对callcontent的解释. CallContext 是类似于方法调用的线程本地存储区的专用集合对象,并提供对每个逻辑执行线程都唯一的数据槽.数据槽不在其他逻辑线程上的调用上下文之间共享.当 CallContext 沿执行代码路径往返传播并且由该路径中的各个对象检查时,可将对象添加到其中. 也就是说,当前线程对对象进行储存到线程本地

MFC 分UI线程和工作线程,一般现在的应用程序都是一个主UI线程和N个工作线程来完成工作.主UI线程获取到工作线程发送的信息来刷新界面. 不过因为工作需要,MFC有要维护的项目,因此就学习一下MFC创建UI线程,使用工作线程的方式. 1.UI线程,继承CWinThread类 class CAddDeviceApp : public CWinThread { DECLARE_DYNCREATE(CAddDeviceApp) protected: CAddDeviceApp(); public:

抽象一个数据库访问层的统一入口(类似于EF的上下文,拿到上下文,就可以拿到所有的表).实际这个入口就是一个类,类里面有所有的仓储对应的属性.这样,只要拿到这个类的实例,就可以点出所有的仓储,我们在 Repository层里面添加一个类 DbSession.cs namespace YouJiao.MvcWeb.Repository { /// <summary> /// 相当于是简单工厂:通过DbSession可以拿到所有的仓储的实例,所以我们也可以将此DbSession看做是简单工厂. //

原文:ASP.NET MVC+EF框架+EasyUI实现权限管理系列(8)-DbSession线程内唯一 ASP.NET MVC+EF框架+EasyUI实现权限管系列 (开篇)   (1):框架搭建    (2):数据库访问层的设计Demo    (3):面向接口编程   (4 ):业务逻辑层的封装  (5):前台Jquery easyUI实现   (6):EF上下文实例管理   (7):DBSession的封装 前言:通过上篇博客我们完成了对DbSession的代码编写,DbSession就相

在软件世界分层的思想无处不在 主要是为了提高软件系统的维护性,扩展性,复用性和解耦等 软件的三层构架是一种最基本的分层思想的体现 结构图大体如下: 如此一来,开发人员可以只关注其中一层,而无需关心下一层是如何实现的 但是最基本的三层构架在软件系统中很明显是不够用的 因为它带来优点的同时也带着许多缺点,比如耦合性高,经常出现修改某一层的代码另外一层也要随之大幅度整顿 而且当需求发生改变的时候,如:原先开发的时候使用mssql数据库,而现在又要求更换成mysql数据库 更换Dal层会导致Bll层也要

如果说,一个对象保证全局唯一,大家肯定会想到一个经典的设计模式:单例模式,如果要使用的对象必须是线程内唯一的呢? 数据槽:CallContext,ok看下msdn对callcontent的解释. CallContext 是类似于方法调用的线程本地存储区的专用集合对象,并提供对每个逻辑执行线程都唯一的数据槽.数据槽不在其他逻辑线程上的调用上下文之间共享.当 CallContext 沿执行代码路径往返传播并且由该路径中的各个对象检查时,可将对象添加到其中. 也就是说,当前线程对对象进行储存到线程本地

尽量不要在MFC线程中将CWnd作为参数传递,会引起crash 正确的做法: 1. 将CWnd对应的handle传进来,通过CWnd::FromHandle()函数转换: 2. 在线程中用SendMessage/PostMessage的方式进行通信.

单例模式 --> 多个用户会使用同一个EF,且这个EF一直不能释放,EF追踪的数据越来越多,服务器内存迟早爆炸(联想应用程序池,用户可能会用到被人用过的Application,里面的EF也是被用过的) 线程内唯一 --> 用户使用同一个EF A(new EF(),此时还没SaveChanges())-->B(判断线程内有无EF)-->C(判断线程内有无EF)-->SaveChanges()-->结束-->释放EF HttpContext.Current.Items

在软件世界分层的思想无处不在 主要是为了提高软件系统的维护性,扩展性,复用性和解耦等 软件的三层构架是一种最基本的分层思想的体现 结构图大体如下: 如此一来,开发人员可以只关注其中一层,而无需关心下一层是如何实现的 但是最基本的三层构架在软件系统中很明显是不够用的 因为它带来优点的同时也带着许多缺点,比如耦合性高,经常出现修改某一层的代码另外一层也要随之大幅度整顿 而且当需求发生改变的时候,如:原先开发的时候使用mssql数据库,而现在又要求更换成mysql数据库 更换Dal层会导致Bll层也要

在一次请求中,即一个线程内,若是用到EF数据上下文对象,就创建一个,那么会造成数据混乱,每次创建的对象执行相应的数据库操作,此同时,其他的EF对象内获得的数据可能已经是“过期”的了.即这个数据已经变动过.这就是数据混乱,为了解决这个问题,关键就是对象的创建问题. 这里首先想到单例模式,不过在这里,不适合用,原因是使用单例模式,会使EF对象得不到及时的资源释放. 第二种方式即保证在线程内对象唯一,如何保证呢,通过微软ASP机制的HttpContext对象,这个对象在线程中是唯一的,所以我们在Htt

CallContext 是类似于方法调用的线程本地存储区的专用集合对象,并提供对每个逻辑执行线程都唯一的数据槽.数据槽不在其他逻辑线程上的调用上下文之间共享.当 CallContext 沿执行代码路径往返传播并且由该路径中的各个对象检查时,可将对象添加到其中. public class DbContextFactory { public static DbContext CreateDbContext() { DbContext dbContext = (DbContext)CallContex

为何只能在其关联的线程内启动timer? 在QTimer源码分析(以Windows下实现为例) 一文中,我们谈到: QTimer的是通过QObject的timerEvent()实现的,开启和关闭定时器是通过QObject的startTimer()和killTimer完成的. startTimer最终调用对象关联线程的eventDispatcher来注册定时器: int QObject::startTimer(int interval) { Q_D(QObject); return d->thre

EntityFramework的线程内唯一 EntityFramework的线程内唯一是通过httpcontext来实现的 public static DbContext DbContext() { DbContext dbContext = HttpContext.Current.Items["dbContext"] as DbContext; if (dbContext == null) { dbContext = new WebEntities(); HttpContext.Cu

有这样一个场景,在vm中,我们为了ui的体验,会异步访问后端接口,获取数据集合,如果这个集合绑定到界面,并且在线程内,怎么处理? 有人讲:this.Dispatcher.Invoke,如果在vm内呢?  有人讲:Application.Current.Dispatcher.Invoke 每个集合都包起来?不太舒爽吧.. 这里有个更好的方案介绍给大家,就是SynchronizationContext,同步上下文. 基于WPF的ObservableCollection扩展 public class

线程函数必须是全局函数或静态成员函数. 非静态成员函数都有一个隐含的参数用于接收所属类的this指针,一般情况下调用时参数不匹配.所以static可以干掉隐含的参数. 但是没有了this,类内的函数就无法调用了.所以AfxBeginThread(线程函数,(LPVOID)this),this又回来了,这样可以调用啦. CWinThread* AFXAPI AfxBeginThread(AFX_THREADPROC pfnThreadProc, //线程的入口函数,声明一定要如下: UINT My