0

This is obviously a topic that has been discussed many times, however my angle of approach here is a little different. As far as I understand, a STE is considered a POCO (it is not tied to the EF dll in any way), it just has some extra "stuff" inside of it for handling its own change tracking. Assuming the following application layers:

Proj.Web
Proj.Business
Proj.Model
Proj.DataAccess

Assuming lazy loading is not required, and we're running in a 2-tier setup, my understanding is that there would really be no difference between using STEs and POCOs. Since we're on the web and it's a disconnected environment, the choices would be an additional SQL query on the Postback or having to attach the entity and set the properties to modified as necessary. Again (correct me if I'm wrong) the code would look identical.

Lets consider a simple example, we're handling a postback in a webform application:

Person p = PersonManager.GetById(2); //we use the "requery" method
PersonManager.Update(p);

//If we dig into PersonManager.Update() we'll see the following:
PersonRepository.ApplyChanges(p); //we're assuming STEs are used so this API is available
PersonRepository.SaveChanges();

Assuming later down the line we are asked to promote the architecture to a 3-tier, introducing a WCF transport layer in between the Proj.Bussiness and Proj.Web, lets call it Proj.Services. If we were using STEs to begin with, aren't we in a much better spot? All we'd have to do is forward the calls to the business layer, without having to modify it or the repositories in any way:

PersonService.Update(Person p)
{
    PersonManager.Update(p);
}

If for example we were using POCOs (lets assume snapshot), we'd have to code in a way where we have to check if this entity already exists in the context (if we're running 2-tier) and if not (3-tier) attach it and set it's properties to modified. Seems like a lot more work when you're not sure if a 3-tier solution would be needed in the future. On the other hand if you were coding against STEs all along, the only extra unnecessary (which doesn't really harm anything) code you would have put in is a call to ApplyChanges(). Otherwise I don't think you're losing anything (again assuming lazy loading is not required). What are your thoughts on the subject?

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
e36M3
  • 5,952
  • 6
  • 36
  • 47
  • Onion architecture maybe? true you dont really need to plan for a 3 tier architecture but to me it feels far more natural. Is not a 3 tier app Ui layer, business logic - can anyone update the data? permissions? Domian model? then you have persistance with data access... Or my understanding is well off please do correct me... – Haroon Jul 18 '11 at 18:41
  • @Haroon, What you refer to as 3-tier is really a 3-layer (logical), but can be run in 2-tiers (physical). I am not sure I understand where you're going with your other questions. – e36M3 Jul 18 '11 at 18:46
  • @e36M3 - Sadly, the term "Tier" has lost all meaning in todays industry, and it's hopeless to try and reclaim it for it's true purpose. For all intents and purposes, a Tier is a Layer these days. – Erik Funkenbusch Jul 18 '11 at 19:34
  • @Mystere Man: Just because there is too many developers who doesn't understand the difference. Even these days it is very important to differ between layer and tier - logical and physical boundary. – Ladislav Mrnka Jul 18 '11 at 20:50
  • @Ladislav Mrnka - Not just developers.. Books even make this mistake. I've tried to argue this with other developers and managers, they just don't get it. There is almost nobody left that knows the real thing, so it's a futile position. Just accept it and fight a battle you can win. It's like trying to convince people to use natural keys in a database rather than slam identity columns on everything. – Erik Funkenbusch Jul 18 '11 at 20:58

2 Answers2

2

STEs are not very well suited for web application. Their problem is how they work:

  • You load STE and close the context
  • Work with data provided in STE
  • Push data back to STE
  • You apply changes from STE to a new context and it simply pass all changes in object graph

That seems like great feature but perhaps it is not. In case of ASP.NET it most often means:

  • Load data for initial retrieval request and store STE somewhere
  • Get data back in following update request and fill data back to stored STE

That is awful because it requires you to store STE either in session or view state.

The approach you described will work in another way. You will not store STE from initial request but you will call your service twice in your updating request

  • First time to get a new STE
  • Second time to pass the updated STE back

That is not much better because you have additional remote call which can transfer a lot of data (object graph) and after that pass whole object graph back.

Obviously both approaches violates some architectonic ideas

  • Don't store unnecessary state in web application because web application should be state less as possible
  • Reduce remote calls to minimum because they are very costly + reduce amount of transferred data to data you really have to pass

They can make remote scenarios much more easier but they have their own costs (and they are .NET-.NET solution). There is no single reason to use them if you don't have remote scenario = If you don't have to use STEs simply don't do that. Moreover there are reports with some problems with their implementation. At user voice you can even find suggestion that they don't work at all.

Community
  • 1
  • 1
Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • all very good points. I am making the assumption that the additional query/remote call are "ok", I think under that assumption my theory stands true. However if we want to stay away from the additional query and STEs all together. What is your recommendation for writing code that is easily updated from a 2-tier to a 3-tier solution? Would you do something like what I described in my last paragraph about conditional attaches? – e36M3 Jul 19 '11 at 14:07
  • My personal opinion is - don't create architecture for something that is not required at the moment because "it will be perhaps needed in the future" means nothing. You should redesign / refactor the application once you have real requirement for that with all its details. – Ladislav Mrnka Jul 19 '11 at 21:38
  • I understand what you mean. The real reason I'm asking is because in the future I foresee having to build an internal piece against the same EDMX using silverlight, so a disconnected scenario will likely happen. I wanted to be able to share my existing model and business logic. I am thinking that if I start with STEs to begin with then there is no harm, but later it'll really pay off when I do have to introduce WCF. – e36M3 Jul 21 '11 at 11:44
  • @LadislavMrnka Great answer as usual. After using POCOs a lot and reading answers to lots of questions similar to this on SO (many of those your answers), I still don't understand... What **are** STEs good for? In what scenarios do you **need** them? What were they intended to do and what when wrong (or right?) Hmm, perhaps I should add a question to SO for this. – Danny Varod Jul 12 '12 at 17:44
  • @DannyVarod: [This answer](http://stackoverflow.com/questions/5091974/what-is-the-purpose-of-self-tracking-entities/5092097#5092097) describes what STEs were supposed to solve. The new approach is to use WCF Data Services for client side change tracking instead of passing all tracking information inside every entity. – Ladislav Mrnka Jul 12 '12 at 18:54
0

Ladislav Mknka made some excellent points on why NOT to use STEs, however it seems there really isn't a one size fits all answer to this question. For example in my current 2-tier project, they might be unnecessary. However we're strongly looking at utilizing Silverlight for an administration piece of this project in the future. This will mean that I have one project for the model and repositories, that hopefully will be utilized across both higher layer projects. So one running 2-tier and another running 3-tier (since Silverlight requires services). As far as I can tell STEs behave just like snapshot POCOs in a "connected" environment, so I don't lose/gain much by using them as such in a 2-tier app. However they'll likely prove to be very useful when we add the 3-tier Silverlight piece. Hopefully the method described in my original post will prove to work well for both types of applications.

There are obviously other ways to solve this problem, one could always write their repositories in a way where they determine if a specific entity is being tracked and perform the necessary tasks based on that decision, I tend to think that going down that path would prove to be much more costly in terms of development effort. I suppose only time will tell.

e36M3
  • 5,952
  • 6
  • 36
  • 47