谈谈某个函数如何考虑健壮性，全面性等？
谈谈数据库锁机制的应用？
谈谈如何做的系统异常处理？
产品交付客户后，客户要求增加一个字段，如何处理？
谈谈新技术 如wcf linq
。我08年毕业的，感觉这些问题有点深，还好进入复试了，大家谈谈自己对问题的看法
谈谈数据库锁机制的应用？
谈谈如何做的系统异常处理？
产品交付客户后，客户要求增加一个字段，如何处理？
谈谈新技术 如wcf linq
。我08年毕业的，感觉这些问题有点深，还好进入复试了，大家谈谈自己对问题的看法
解决方案 »
- 如何禁用aspx页面默认回车问题
- asp.net URL地址问题
- 老提示MaileMessage已过时
- 帮忙解决一下循环问题
- webconfig中的特殊字符问题?
- Nhibernate 问题求助，在线等，急，分数全部送上。
- 一个简单的问题。。。
- [加50分求助] ( select * from 表名 where function(@col)='关键字' ) 其中@col是一个字符串变量，代表‘表’中某个字段,有function(@col
- 请问application,session,cookie的用法。
- 怎么在一个.aspx的页里导入一个.HTML的文件(高手请进)
- ASP.NET面试题 大家评价一下 66道
- 毕业设计是个网上选课系统。下到了了一堆aspx。aspx。cs
我用了单例模式，操作数据库用的是C#3.5的Linq,这样就会只存在一个操作数据库的实例，但是问题来了，当偶然抛出一个操作数据库的异常之后，其他的的除了查询正常之外，update,insert,delete 操作都会抛出同样的异常，我还以为是服务器的配置问题呢郁闷，测试后估计是Linq在抛出异常之后它的状态会一直保持异常。后来全部改成new出一个实例，问题没有了。
对于第一个问题，我想到了高内聚
第二个问题，排他锁，共享锁等
第三个问题，系统异常也就知道trycatch，提示出现系统异常，记录错误日志
第四个问题，看情况，能不加就不加。。或用其他方式处理。。
第五个问题，看过了解点概念，具体没用过
不知道lz面试的什么职位，我明年毕业，还真没被问过这样的问题，大部分是。net的基本常识，数据库的简单操作，以及数据结构上的一些知识-------------------------------------
年后找工作 有谁哪里缺人么？我自我推荐下，呵呵
数据库锁机制的应用？概念以及原理不算的...系统异常处理？不是try catch这么简单的..
2.共享锁，排他锁等
3.try catch---程序里不要抛出未处理的异常，所有的异常信息统一管理，统一记录到一个文件里。
4.非常简单，加钱
5.不懂。不用过。
知道的就这么多了，结果发现貌似还被BS.....
避免重新生成代码的确很诱人，不过我没见过。
像Hibernate这种都是要重新生成代码的
然后生成一个工厂类，存储这些信息
需要时，用这个类生产Command对象
对于频繁使用的方法 也可以适当的缓存Command对象吧其他工作就是把适当的表单数据转换为 正确的 数据，填入Command对象执行
1:采用传统的二层模式开发
2：有一种真正三层模式也是不需要生成表实体的，它的所有Sql语句操作都是写在配置文件中或写进数据库的表中，表现层只需标明需要执行的语句序号就可以了
给个MySql数据库锁机制原理参考：
谈谈数据库锁机制的应用？
http://edu.cnzz.cn/NewsInfo/25902.aspx
2. 锁机制,一般来说共享锁多一点吧. 不如更新数据的时候... 我是没具体应用过,, 看过书.
3, 异常处理,首先要跳转到统一友好的报错页面, 自己要记录报错内容.
4. 数据库设计,一般我设计表都会有3个预留字段,作为扩充.交付的话, 如果考虑赚多一点钱的话,就要加钱,如果你老实一点, 就说好,这个我已经给你留了一个字段如此云云.
5. wcf也只是一种WebService的新的扩展吧, 支持了更多的协议, 让c++调用也不用写托管程序啥的... 多一些开发效率... 其次 linq没啥好说的,, linq的市场在萎缩 , 现在主要应用在linq to sql了....
。
数据库锁，了解不多，更不用提机制问题，只知道乐观锁，和悲观锁，
加字段的问题很好解决，一般做后台留一个执行SQL语句的地方，客户要加字段，
直接执行SQL语句就可以了，这样做不是很好，最好在设计数据库时候多预留几个字段
谈谈数据库锁机制的应用？ 很基础--加锁和解锁--事务相关---很基础
谈谈如何做的系统异常处理？ 不说了 很基础--现在help。dll
产品交付客户后，客户要求增加一个字段，如何处理？ 尽量婉拒，他们想知道你怎样和客户交流
谈谈新技术 如wcf linq www.google.com
----
问题很好，估计招年轻的新人。
目前我们公司的产品数据库增加字段就能不需要重新生成代码，只需要修改配置文件
数据库嘛，不就是数据库名，表名，列名和数据关系么
往配置文件一写，读取配置生成sql语句就完了，数据库的改动配合配置文件改动，代码一句都不要动
客户要求加字段 在你设计数据库的时候 就应该考虑的 增加1-2个扩展字段来应付客户的这些要求
LINQ是好东西 对开发效率应该有很大的提高 WCF目前没怎么用过
简单点评一下吧。呵呵，实际上这类问题针对不同人有不同回答，只是看出背景和思路，未必有什么“标准”答案。1. 函数有什么健壮性？函数按照需要而设计，因此一个程序员只要完成pm或者架构师给它在“文字的”工单中描述的要求，就没有责任了。如果函数不够“健壮、全面”，我认为应该由pm负责。有些pm在写工单时没有掌握写清基本的功能说明书的技巧，它把设计责任推卸给低级的程序员来完成然后对其提交的“设计”说三道四地批评，这是不对的，我比较倾向于pm应该勇敢地给程序员免除责任。实际上，优先考虑开发时间。例如1天不能完成的事情，就不要再去纠缠什么“全面”。当你做完一天的事情，测试已经通过，那么你就可以补充新的测试来驱动进行重构，新的测试跟老的测试叠加在一起保证事情有进展——而不是在第一天就不切实际地要求什么“全面”。没有什么完美地开发，任何程序都难免要被重写的。有经验的pm应该让很低级的程序员也能大胆放手写程序，而“强壮、全面”这类东西则是对pm的要求，而不是对低级程序员的要求。2. 关系数据库，通行的机制是高层次的事务，例如对于查询我们可以在事务的开始声明它采取READ UNCOMMITTED
或者读取快照的方式。只有一些很低级的数据库编程采取直接使用锁。3. 除非必要（在业务逻辑设计时依据用户的逻辑而设计了），不要想当然地去捕获异常。因此捕获异常往往只是对应应用领域的设计。如果涉及纯粹计算机领域的概念而发生的异常，不应该捕获异常。系统表现层（肯定必须）会最终捕获异常。4. 产品交付客户后，客户要求增加一个字段？换个产品经历吧！因为他误导了外部客户，也误导了团队。满脑子底层编程术语，必定很快搅乱产品设计。产品更新，只是修改产品的界面和交互行为设计，而不是什么字段。只有认识到这一层，才能避免从程序员那点小心眼（通常是自己图省事而去指责用户需求有问题）出发去跟客户扯皮。我们可以站在用户那个行业里边的大半个业务专家的角度去跟用户讨论业务设计如何更有效益的问题，而不是什么字段的问题。5. 能问出什么水平的问题，才能得到什么水平的回答。