马上要入职互联网行业了,我需要了解些什么?
1. 基础技能 - 会与人打交道
- 对公司的产品有良好的认知
2. 高阶技能
- 谈判技巧
- 对本司的产品理念以及行业的发展方向有自己的理解
基础的第一条其实是挺废话的，但恰恰是很多人都不具备的技能。而且不是看书就可以学会的东西，只能在工作中成长起来，这种时候跟对一个好的领导非常重要啦。
见过姿态过低整天只知道跪求人的乙方BD，也见过对人爱理不理觉得自己背靠大公司牛得不得了的甲方BD。听上去很幼稚小儿科吧？但这种人太多太多了，不具备最起码的交流沟通技巧的人也太多太多了，比如整天在Q上找人只会问“在吗？”的……
其实上面两段还是废话啊哈哈哈哈哈哈，但是做人这种事情真的需要自己学┑(￣Д ￣)┍
有次一个甲方商务跟我哭诉一个乙方商务缠着他问一些很基础的问题，其实都是在官网上自己看一遍流程都能了解的东西，最后对方总结说，啊，这就是两千块跟八千块商务的差别！然而在这位甲方商务的合作群里面，我还是会看到前仆后继各种乙方商务整天伸手讨要一些自己动动手指就能了解的信息。
你说，这种自发去学习，尽量不麻烦他人的习惯，是属于怎样才可以培养的技能呢？
第二条是因为商务这个工种门槛较低，不需要什么专业知识就可以上手，看提问说没有相关经验也印证了我这样的想法。于是遇到过很多一线的商务根本不了解自己公司的产品，但开口就是要合作要资源，拿着运营或者市场做的ppt出来照本宣科……小公司特别容易招到这种商务，基本碰到这种情况，我是产品看都不看就不考虑合作的（啊，也是非常不好的习惯！但我改不掉！）
谈判技巧我放在高阶技能，也是因为大部分的一线商务只是带着领导的指令以及KPI出来当复读机。曾经有个商务对我说，他最主要的工作，就是用自己最差的资源，去换别人最好的资源。听上去有点夸张，但他确实经常能做到，并且还不影响后续的合作，所以呐，其实也不是真的用自己最差的资源去置换，而是可以找到让双方都互赢的办法，可能对自己无用的资源在别人手中是至宝呢？
谈判技巧怎么提高呢？擦，我也不知道，因为本人碰到谈判瞬间智商为零，出去买东西一个15一个18，我会弱弱地说，老板娘两个35行不行。不过有机会就多参加自己领导跟别人的会谈，还是可以学到很多方法！！
现在的年轻人应该对电脑掌握到什么程度？
谬论！
玩游戏的朋友我不否认在某些方面还勉强过得去（主要就是知道玩什么游戏用什么显卡，还有什么DX之类）
但是他们却连windows的基本操作都不太会。跟本没有能力去解决自己遇到的问题。
一个人的电脑水平并不是综合的，精通编成，精通flash制作，精通CAD的却连windows有几个版本都搞不清楚的大有人在，但是他们也是高手，是“术业有专攻”的高手。
一个人不可能精通计算机所有领域，你应该想清楚，自己是想向编成发展还是作一个troubleshooting。比如我精通xp和硬件，但是编成却几乎一点不懂。
想要学习计算机的初学者一定要看清自己的方向，或许你先学习安全技术也是个不错的选择。
有什么问题可以给我法邮件
muzheyun#gmail.com
请将#改为@
在ASP.NET中如何应用三层架构方式实现多表连接事务处理？
区分层次的目的即为了“高内聚，低耦合”的思想。1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。三层结构原理：3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。表示层位于最外层（最上层），离用户最近。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。业务逻辑层业务逻辑层（Business Logic Layer）无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为领域层。例如Martin Fowler在《Patterns of Enterprise Application Architecture》一书中，将整个架构分为三个主要的层：表示层、领域层和数据源层。作为领域驱动设计的先驱Eric Evans，对业务逻辑层作了更细致地划分，细分为应用层与领域层，通过分层进一步将领域逻辑与领域逻辑的解决方案分离。业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此，业务逻辑层的设计对于一个支持可扩展的架构尤为关键，因为它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，则是除了实现业务逻辑之外留给设计师的任务。数据层数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问，可以访问数据库系统、二进制文件、文本文档或是XML文档。简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。三层结构的程序不是说把项目分成DAL, BLL, WebUI三个模块就叫三层了, 下面几个问题在你的项目里面：如果不是所有答案都为YES, 那么你的项目还不能算是严格意义上的三层程序. 三层程序有一些需要约定遵守的规则：1. 最关键的, UI层只能作为一个外壳, 不能包含任何BizLogic的处理过程2. 设计时应该从BLL出发, 而不是UI出发. BLL层在API上应该实现所有BizLogic, 以面向对象的方式3. 不管数据层是一个简单的SqlHelper也好, 还是带有Mapping过的Classes也好, 应该在一定的抽象程度上做到系统无关4. 不管使用COM+(Enterprise Service), 还是Remoting, 还是WebService之类的远程对象技术, 不管部署的时候是不是真的分别部署到不同的服务器上, 最起码在设计的时候要做这样的考虑, 更远的, 还得考虑多台服务器通过负载均衡作集群所以考虑一个项目是不是应该应用三层/多层设计时, 先得考虑下是不是真的需要?
.net数据库多表操作时的事务处理对象如何使用，以实现原子事务的处理效果。
我的做法是，更新数据库之前，先把所有要操作的SQL语句放到一个List里面，然后传给数据库操作的那个类来一起处理事务。
#region 批量运行SQL语句（事务处理） ----单向操作(添，删，改)
public static bool BatchRunSQL(ArrayList list)
{
//连接对象 //指定对象的作用域范围
using(OleDbConnection con = new OleDbConnection())
{
con.ConnectionString = getConnectionString();
con.Open();
using (OleDbTransaction transaction = con.BeginTransaction())
{
try
{
//用命令对象实现功能
OleDbCommand cmd = new OleDbCommand();
int count = 0;
cmd.Transaction = transaction;
cmd.Connection = con;
for (int i = 0; i < list.Count; i++)
{
string sql = list[i].ToString();
cmd.CommandType = CommandType.Text;
cmd.CommandText = sql;
//用命令对象实现功能
//执行，得到影响的行数
count += cmd.ExecuteNonQuery();
}
transaction.Commit();
if (count > 0)
{
return true;
}
}
catch (Exception e)
{
transaction.Rollback();
throw new Exception(e.Message);
}
}
}
return false;
}
#endregion
