Standard Architecture ~ Should the business layer focus on data persistence?

Business Layer, you do not know the implementation details of the database

This topic is also widely discussed on the Internet. Will your business layer contain your data layer-related architecture technologies? For example, your data layer persistence is implemented through EF, so should your business layer also introduce entityframeworks assembly? Occupy shares will tell you, no, because this will make your business no longer purely business, it will depend on the technology implemented by your data layer persistence, this is wrong, we need to extract the business layer. In this way, the business layer will not be affected when your data layer performs technical switching. Of course, this is a matter of course,If your database has changed technology and affects your business layer, your architecture itself will fail!

My EF architecture failed

In my ef architecture, the business layer uses the entityframeworks Assembly implemented by the data layer. It knows too many persistence methods, so it fails and you fail, because you make it impossible for me to switch from one ORM to another.

The cause of the failure.

Entityframeworks is referenced at the business layer because it is a "transaction". To ensure data consistency, we add transaction blocks to the program. Sometimes, for sql2005, it will increase local transactions to distributed transactions, which is undoubtedly a burden for the system. Therefore, I can only rewrite this transaction block, after rewriting, it will not trigger distributed transactions, but there is also a painful price, that is, a local transaction needs to be specific to the same "data context ", that is, the dbcontext object in entityframeworks. Therefore, the BLL layer depends on EF, and failure is understandable.

Sql2008 is beautiful

When SQL Server is upgraded to 2008, it seems to find something, which may be a bad taste, a bad taste of code. In sql2005, a statement is sent to the SQL end, it will reset an SQL link. It is a reset that causes net to treat this process as a distributed transaction. In sql2008, if your database is, then it will think that your process is a local session process, that is, local session and local transaction!

My contribution

The following is the solution code that does not trigger MSDTC in the same context of sql2005.

/// <Summary> /// Author: Zhang. zhanling // synchronous article: http://www.cnblogs.com/lori/p/3455393.html // For transactionscope, so that it does not produce MSDTC service for the same database // environment: sql2005, sql2008 has fixed this issue. // </Summary> public class transactionscopenomsdtc {// <summary> // generates a package transaction // maintains a connection object // /</Summary> /// <Param name = "DB"> data context </param> /// <Param name = "isoutest"> indicates whether the data is the outermost layer, the default value is false. </param> /// <Param name = "action"> process the code block. </Param> Public static void usingnomsdtc (iunitofwork dB, bool isoutest, action Action) {var objectcontext = (system. data. entity. infrastructure. iobjectcontextadapter) dB ). objectcontext; try {If (objectcontext. connection. state = system. data. connectionstate. closed) objectcontext. connection. open (); Using (transactionscope trans = new transactionscope () {Action (); Trans. complete () ;}} finally {I F (isoutest) // if the transaction is the outermost layer, close the connection! The internal transaction and the external transaction need to share a connection objectcontext. connection. close (); // can only be closed, not dispose, because after dispose, the context will not be able to get the link string }}/// <summary> // generate a package transaction, it is not the outermost layer, if it is the outermost layer, you need to call other heavy loads. // </Summary> /// <Param name = "DB"> </param> /// <Param name = "Action "> </param> Public static void usingnomsdtc (iunitofwork dB, action action) {usingnomsdtc (dB, false, Action );}}

 

Standard Architecture ~ Should the business layer focus on data persistence?