0

I'm defining a 3-tier architecture for a web application. Due to high availibility requirements, i have defined to deploy the business layer (BL) and the data access layer (DAL) in a cluster of two nodes, and the presentacion layer (PL) in two physical servers that can be accesed through a load balancer. The data access layer will be implemented using Entity Framework 4.0 (EF).

Using entity framework is possible to generate Self-Tracking entities that solve the problems of having a N-tier architecture (For more info http://msdn.microsoft.com/en-us/magazine/ee321569.aspx), but i'm not sure if it is a feature that can be used in the scenario where an entity is queried from a node of the cluster using an EF DbContext 1, then is modified in the remote PL, and finally it is saved in the another cluster node using an EF DBContext 2. I'm assuming that in this case a distributed cache solution should be used to unify the EF DBcontexts, thus the nodes of the cluster could use the same context, but i wanna make sure that there is not a simpler solution.

1- ¿Does Self-Tracking entities work well in the scenario described?

2- ¿What is the common solution to this situation?

Thanks in advance

jmurcia
  • 1
  • Two things, firstly im not sure what problem you are trying to solve with STEs, perhaps expand on what you feel the issue is with regular centrally tracked EF. And secondly STEs are deprecated and shouldn't be used at all anymore. – undefined Jun 16 '13 at 02:44
  • Luke, the problem is that i'm not sure if by using two EF DBContext in two diferents servers (in cluster mode) will be a problem when the entities will be extracted from DBContext 1, updated in the PL that will be remotely located, and then updated in the DBContext 2. – jmurcia Jun 16 '13 at 19:56
  • EF is really just a layer across the top of regular SQL infrastructure which handles your mirroring. Normally you would configure SQL to mirror in a cluster configuration. This is completely transparent to consumers (such as EF) and all they need to do is use a clustered connection string. – undefined Jun 16 '13 at 20:00
  • ... I'm just know the basic about the Entity Framework and may be i'm seeing a problem that might not exist. I just wanna make sure that i'm not gonna have problems in the future – jmurcia Jun 16 '13 at 20:02
  • Luke i apreciate your help. In this case, the configuration of a cluster in the DB is not an option due to restrictions not relevants here. Unattach an entity in the DBContext 1 and then attach that entity in the DBContext 2 in a diferent servers will not become a problem due to tracking changes issues? – jmurcia Jun 16 '13 at 20:12
  • so if I understand you are trying to do clustering by writing to two disconnected SQL servers from your WFEs? – undefined Jun 16 '13 at 20:18
  • Not at all. My architecture: Tier 1: Load balancer, balancing the load between two servers running IIS each one running the PL-ASP.MVC Tier 2: BL exposing WCF interfaces based on DTO and EF entities and the DAL using EF. All this tier run in an IIS cluster of two servers Tier 3: One database I'm trying to access to one SQL server, from two differents intances of the EF running in a IIS cluster where one intance could be used to get an entity from DB an the another one could be used to update the changes done in the remote PL. will this become a change tracking issue for the EF? – jmurcia Jun 16 '13 at 21:02

0 Answers0