评论一下内容优点和缺点，如何做更好~public interface ITrade{void UpdateTradeByTid(string Tid)bool Ch
评论一下内容优点和缺点，如何做更好~
public interface ITrade
{
void UpdateTradeByTid(string Tid);
bool CheckTrade(string Tid);
void InsertTrade(TB_Trade trade);
TB_Trade GetTrade(string Tid);
}
public class Trade : ITrade
{
public void UpdateTradeByTid(string Tid)
{
TB_Trade trade = GetTrade(Tid);
if (trade == null)
{
trade = new TB_Trade();
InsertTrade(trade);
}
else
{
using (GuoTBManageEntities context = new GuoTBManageEntities())
{
context.Entry(trade).State = EntityState.Modified;
context.SaveChanges();
}
}
}
public bool CheckTrade(string Tid)
{
TB_Trade trade=GetTrade(Tid);
return trade == null ? false : true;
}
public void InsertTrade(TB_Trade trade)
{
try
{
using (GuoTBManageEntities context = new GuoTBManageEntities())
{
context.TB_Trades.Add(trade);
context.SaveChanges();
}
}
catch { }
finally {
throw new ArgumentNullException("添加订单信息失败~");
}
}
public TB_Trade GetTrade(string Tid)
{
using (GuoTBManageEntities context = new GuoTBManageEntities())
{
return context.TB_Trades.SingleOrDefault(U => U.tid == Tid);
}
}
}
接口与继承，并处理业务关系
[最优解释]throw new ArgumentNullException("添加订单信息失败~");
这行在 finally 里每次执行不论成功与否都会抛出异常
[其他解释]只有插入有抛异常。修改等没有抛异常
[其他解释]哥来评审一下你的代码；
不说风格，哥觉得你代码逻辑有点问题!
TB_Trade trade = GetTrade(Tid);
if (trade == null)
{
trade = new TB_Trade();
InsertTrade(trade);
}
应该改为
TB_Trade trade = GetTrade(Tid);
if (trade == null)
{
trade = new TB_Trade(Tid);
InsertTrade(trade);
}
之类，因为如果不存在的话，你要插入一个新的，但是新的缺没有任何构造参数，那这个新的Trade不是一个空的毫无意义的吗？
再个，UpdateTradeByTid中不应该存在添加Trade的功能，UpdateTradeByTid的功能应该唯一，只更新，如果不存在，就直接报错。因为你怎么知道人家所有的需求都是更新不成就插入？我还要求更新一个不存在的单子，就直接报错呢。
再个，除了public TB_Trade GetTrade(string Tid)之外，我认为所有的UpdateTradeByTid，CheckTrade， InsertTrade都应该使用 Trade t参数，而不应该使用string tid参数。
最后，本人认为不应该使用Entities framework， 这玩意太新鲜，奉劝楼主，还是把最基本功练好再说吧。
你练好了基本功，这些新特性更本不用搭理。
[其他解释]一个好用的DAL应该跟业务没有直接的耦合性，它不应该“为了三层而三层”，它不应该像早先的PetShop那样悲催地手工写一大堆围绕业务实体的“增删改查”，而应该像ADO.NET、Linq to EF或者真正的ORM那样与业务实体分离。
已经有了EF，你就应该直接使用它。它可以直接方便地处理Trade实体的数据库操作，那么就不要在这个灵活的工具上封装一层“裹尸布”，不要再去紧紧围绕Trade实体去封装出什么“Update、Check、Insert、Get”方法出来！
如果你使用标准的关系数据库，对于“惧怕EF”的人，除非你能写出更好的框架，否者还是多用用EF吧。
[其他解释]
如果你是为了应聘，如果你以为许多公司还是以PetShop式的所谓DAL方法为“三层方法”中的DAL，于是你必须在强大的EF之上再围绕着每一个实体类型而封装什么“增删改查”DAL代码，我觉得这是很悲剧的。这就好象是应邀在宝马汽车上面画上一头驴（把它伪装成驴才能上路行驶），把这个强大而通用的DAL工具变成PetShop式的悲催DAL风格，实在是（最早期ORM）十年死亡之后泛出的一种腐烂的味道。
[其他解释]
我们分不同的层次。有些核心技术部分使用Socket+自定义通讯网关+MongoDB，而一些简单的表现层和业务逻辑层（也是全国业务最复杂的大型企业的系统）则为了让程序员“容易上手”而使用WCF+RIA Service+SQLServer。我相信这方面一般实用的应用技术点应该算是比较了解的。
多线程传一条数据怎么了？这是正常的业务逻辑。这就好比如说两个派出所同时给一个小孩办理身份证，系统自然就要报错。这是业务逻辑，应该站在业务逻辑的高度上明确处理。而不用纠结在数据库问题这个层面上。
[其他解释]我说的是：你使用了EF，就不要在写什么
public interface ITrade
{
.......
}
这类代码了。在业务处理层面，当需要对于底层的数据库操作，直接调用EF方法进行“增删改查”就行了，没有必要再搞个单独的 ITrade 出来。
[其他解释]不要硬要移植sql语句到EF。
你的程序假设遇到业务上重复提交（由于数据库一致性而不允许重复插入）实体引起异常，那么后一个提交此数据的程序的界面上就显示提示信息了，用户就知道他的操作失败，用户就进行其他的处理。这根本不需要在技术上找什么“解决办法”，这种异常处理流程是正常的业务逻辑，不要纠结在数据库操作的sql语句上去处理它。
如果业务逻辑就是那样设计的，那么你或许可以在try...catch....捕获到异常之后，再读取数据库中的数据然后用用户提交的数据进行覆盖、然后再次提交修改操作。但是如果业务逻辑没有那样设计过，你硬要写个sql语句或者让EF自己去把Insert操作变为Update操作，就多此一举了。
无论如何，这是业务逻辑设计问题，不允许数据库编程人员自己想然地去搞什么技术解决。
[其他解释]别听这人的.
微软技术, 你至少使用它3年前的技术, 最好是5年前的技术, 盲目跟这微软新技术跑, 并不能证明你技术多好, 只能证明你是个傻子.
微软就是一个靠不停的卖新软件新产品才让比尔盖茨住上豪华大房子, 成为首富, 建立什么狗屁基金会的. 比尔盖茨为了金钱\地位和享受, 你觉得他会在乎他公司运作的合理不合理吗?
肯定不在乎~ 你跟着他们跑, 那就是成了奴隶了.
[其他解释]根据任务单一原则, 你应该再写一个InsertOrUpdate方法.
别人给你意见,你还狡辩,那你还写出来让别人评审干啥?
[其他解释]哦，写错了~
[其他解释]加注解了地址：
http://www.cnblogs.com/gwd2012/articles/2750929.html
[其他解释]linustd
我没有用构造函数，也没关系吧，我直接生成个空的结构再附值
我这有个区别就是，我想直接在更新的方法里直接完成更新或添加的，需求不一样，环境不一样。
[其他解释]楼上的老大，我一直用的就是EF啊，我这里只是写的逻辑层，做数据处理的， 放便WebAPI操作调用的。
至于EF楼上的老是不是很了解？有一种情况，如果遇到多线程同时传一条主键相同的数据，而EF就不好判断是否要添加还是更新，前题这是异步线程提交，会造成两条数据都是添加行为，程序就出错了，主键不能添加，需要做更新才对。
[其他解释]http://www.cnblogs.com/gwd2012/articles/2752802.html
这是我找的能直接操作SQL的相关资料，然后把实体类和SQL做了结合，封装了下。
我不清楚有没有更好的解决方法。
[其他解释]按你说的，如果用Try Catch 的话，还是一样执行不了啊，客户端捕捉异常再去做更新？我是觉得这样没有直接操作SQL来的放便~
string sqlItemInsertAndUpdate = "IF NOT EXISTS (SELECT " + Key + " FROM [" + TableName + "] WHERE " + Key + "=" + KeyValue + ") BEGIN {0} END ELSE BEGIN {1} END";
我直接把实体类做了这样的封装
[其他解释]
我觉得应该没有影响EF的架构，还是可以代码先行的，我一直以实体类来操作。
[其他解释]
不过，在用EF能执行SQL的时候总是经常报错，具体代码如下：
protected void ExecuteSqlSript(Database database, String command)
{
using (TransactionScope scope = new TransactionScope())
{
var conn = database.Connection;
if (conn.State == ConnectionState.Closed)
conn.Open();
var cmd = conn.CreateCommand();
cmd.CommandText = command;
try
{
cmd.ExecuteNonQuery();
}
catch (Exception e)
{
throw new ApplicationException(e.Message +
"\r\n\r\nCommand: " + command, e);
}
scope.Complete();
}
}
有时候会报错：
事务（进程 ID 189）与另一个进程已被死锁在 lock 资源上，且该事务已被选作死锁牺牲品。请重新运行该事务。
说明: 执行当前 Web 请求期间，出现未处理的异常。请检查堆栈跟踪信息，以了解有关该错误以及代码中导致错误的出处的详细信息。
异常详细信息: System.Exception: 事务（进程 ID 189）与另一个进程已被死锁在 lock 资源上，且该事务已被选作死锁牺牲品。请重新运行该事务。
让人头疼痛，不知道如何处理。
[其他解释]SQL 是全世界的标准, 不由任何一家公司单独掌控, 你凭什么说 SQL 就比 Entities framwork这样一个临时的兴致来了而开发的ORM 就好 ?
微软的DataSet模型是很好的,因为DataSet是微软.net刚推出时, 一批真正的专家设计的, 微软的vs 2003安装目录里有一个书店的例子, 比PetShop还早, 就是展示了如何使用DataSet模型 实现数据访问和程序模型.
微软.net 2.0之后, 微软内部那些不是真正程序员的, 只知道封装, 让他们比尔盖茨\鲍尔默老板喜欢的封装派开发者开始兴起了, 他们设计不了.net基础构架, 之后由专家设计好之后, 他们再出来开发新组件, 以此来不停的推出新东西, 让你花钱购买.
人家那些真正的专家, 是不屑于开发这些无用的组件的.
