评论一下内容优点和缺点，如何做更好~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操作，就多此一举了。
无论如何，这是业务逻辑设计问题，不允许数据库编程人员自己想然地去搞什么技术解决。
[解决办法]根据任务单一原则, 你应该再写一个InsertOrUpdate方法.
别人给你意见,你还狡辩,那你还写出来让别人评审干啥?
[解决办法]别听这人的.
微软技术, 你至少使用它3年前的技术, 最好是5年前的技术, 盲目跟这微软新技术跑, 并不能证明你技术多好, 只能证明你是个傻子.
微软就是一个靠不停的卖新软件新产品才让比尔盖茨住上豪华大房子, 成为首富, 建立什么狗屁基金会的. 比尔盖茨为了金钱\地位和享受, 你觉得他会在乎他公司运作的合理不合理吗?
肯定不在乎~ 你跟着他们跑, 那就是成了奴隶了.
