title: Should I stick onto Entity Framework?
body: <p>I adopted EF (out of box of .NET 4.5) in my new internet web app.</p>
  
  <p>this app do involve quite some operation over db activities, and involve around 30 or more tables.</p>
  
  <p>my point is this is not a simple school project, where EF typically suit for most needs.</p>
  
  <p>as further I developing this app, I found EF very limited or prohibitive for proper/good db design (especially in term over performance)</p>
  
  <p>1) Include</p>
  
  <p>I encountering the Include feature in the query part. Many data missing is due to missing include setting.</p>
  
  <p>the more I putting in this thing, the more I worry a simple data retrieval is getting more things than I needed in certain function.</p>
  
  <p>2) Validation</p>
  
  <p>I'm adopting Fluent Validation for this need, as I prefer the visitor pattern, where no direct code changes needed over the data code itself.</p>
  
  <p>but then I getting more challenges as I subclassing, I need to workout validation able to respect OOP simple stuff. I managed it, though more complexity and certain things I really dislike in its implementation. I believe this subclass validation issue happened in DataAnnotation as well.</p>
  
  <p>3) Transaction</p>
  
  <p>Now, I need to incorporate proper db transactaction control, and I found this lacking in EF, correct me if I'm wrong.</p>
  
  <p>I used to worked with Enterprise component (COM+ in .NET, long-long time ago), and I can't find the proper (or the lack of it) transaction implementation in EF.</p>
  
  <p>I'm still working on this...</p>
  
  <p>concluding)</p>
  
  <p>I come to realize the only thing EF has helped me in my coding, is the data/entity code generation, which this is common feature over many other tool/framework.</p>
  
  <p>I'm thinking to drop this EF, switch back to pre-EF era approach, adopting stored-proc, still code-generated table class (but not EF or DBML).</p>
  
  <p>I can do without SQL LINQ, as I have many challenges over this in past over performance issue.</p>
  
  <p>I like your opinion that I should stay and stick to EF, for whatever reason that my simple mind can perceive, apart from this ORM, which hardly is realistically working at all.</p>