Hello,

I have a situation and I was hoping that the team and users of LLBL may be able to provide me with some assistance.

We have a client that we have provided some LOE's to for some development work. The design is n-tier and distributed with a focus on DDD with a SQL Server 2005 back end. Our initial design has us consuming straight LLBL entities only in the BL and DAL while providing simple DTO's to any "clients" of our services. We have had a decent amount of success with this approach in the past and found LLBL to a great addition to our productivity enhancement tool set. The LOE's were done under the assumption we would be using LLBL. The client has recently informed us that they require us to use Entity Framework and for us NOT to use LLBL. The EF will be the current version, I am not even sure what version that is, that is NOT v4.0 due to the upgrade path.

What I am looking for is any help at in adjusting the LOE's we provided based on the change.

We have no in house "expertise" in EF, nor does the client. The EF approach is basically going to be a "learn as you go" experience on both sides.

Our intention is to use v3.0 to generate our EF code. Outside of that I am looking for any background experience any may have that includes, but is not limited to:

1. Roadblocks encountered - what can we not do (easily, natively, or without writing custom code) in EF that we can in LLBL?

2. What is the difference in turnaround time from database creation/change to functional coding? - with LLBL we experience a development effort of minutes before we can actually begin doing CRUD, whether basic or complex, what about EF?

3. Version limitations/differences that may impact the project.

4. Learning curve to get productive on EF. While all of our developers in house are up to speed and proficient in working with LLBL, no one on either side has any experience doing n-tier with EF. The client has sampled it on a very simple project that involves a stand alone database with less than 10 tables however the bulk of the work we will be doing is targeting an Enterprise environment with n databases, distributed transactions, and most databases will have a significant number of tables normalized to 2nd NF on average.

That is most of what I can come up with for now.

If you have any feedback at all for me that might be useful please feel free to post!

Thank you all in advance!

Harry wrote:

Hello, I have a situation and I was hoping that the team and users of LLBL may be able to provide me with some assistance.

We have a client that we have provided some LOE's to for some development work.

What's an LOE, btw?

The design is n-tier and distributed with a focus on DDD with a SQL Server 2005 back end. Our initial design has us consuming straight LLBL entities only in the BL and DAL while providing simple DTO's to any "clients" of our services. We have had a decent amount of success with this approach in the past and found LLBL to a great addition to our productivity enhancement tool set. The LOE's were done under the assumption we would be using LLBL. The client has recently informed us that they require us to use Entity Framework and for us NOT to use LLBL. The EF will be the current version, I am not even sure what version that is, that is NOT v4.0 due to the upgrade path.

The entity framework v1 (which was released in .NET 3.5 SP1) is absolutely UNUSABLE. We generate code for it, but I'd stay away from it as far as I could. V4 is better, still has a lot of rough edges and quirks and above all limitations, but it's at least usable to some point. v1 is absolutely NOT usable.

What I am looking for is any help at in adjusting the LOE's we provided based on the change.

We have no in house "expertise" in EF, nor does the client. The EF approach is basically going to be a "learn as you go" experience on both sides.

At the start, it's just Linq you need to know with the addition that you have to work with a Context class and not with an adapter. The context is stateful, which is a change of mindset. This can give headaches, especially when entities come back to be saved. That's also why v1 is totally unusable, you have to do the changetracking yourself. The self-tracking entities template for v4 (.NET 4) is better in this, still some work but at least it's doable.

But as I don't know which version you're using, I can't answer your other questions. Besides some limited edge-case linq queries which work in EF v4 and not in our linq provider (though others work in ours and not in theirs) and the fact that EF v4 can do poco and we can't (but that's not really an issue) there's little what EF can do and our framework can't.

Thanks for the reply!

LOE is Level Of Effort, it represents our estimates for work that we provide to management that they then use to provide project detail for client consideration such as design and development schedules to help set and manage expectations and cost.

I believe I was told that the version of EF is v3.5, like I said I know for sure it is not v4.0.

From the limited research I have done I find allot of negative for EF that is concerning me. Such as: 1. EF does not provide for batch processing in a single call, such as UpdateEntitesDirectly. 2. "Developing N-Tiered Applications with EF is difficult. Reattach objects into the data context after client modifications requires too much work." 3. "why is it that the Entity Framework designer is such a pain to use?" 4. "why does it lack true maintenance features like true projection maintenance of T to C for example?"

Management is looking for the short/simple answer of "we told the client x months to deliver but switching to EF will represent and increase of z% resulting in y months to deliver". I understand the over simplification of the request and was hoping to get some real world experience feedback to use as justification for any change we do need to propose.

Thanks again for responding, LLBL team and users have always been extremely helpful to me!

Dear Harry

I’m the lead developer of Funboo. Funboo is an application designed to be used in entertainment centers. Funboo is not known, but those that need to know us, know us. Some of them are the larger centers and festivals.

Funboo works on a lot of data and requires a fast user experience. Two and a half years ago, we started building our application on Entity Framework 1. We had a teacher coming to the company and he trained us one week on the framework. Then we played around with it for several weeks and we had the same trainer coming back for a couple of weeks to assist us on making the object layer.

The teacher I’m talking about here was not just anybody. He is the ADO .net provider author of the firebird project. He explained everything right.

Earlier this year EF4 was released and we converted it to “poco” and we enabled lazy loading.

These are our findings.

EF is really nice for mockup.

EF has the best linq emplementation ever. It is really awesome.

It works nicely together with WPF and all the ms products.

Entity Framework is designed to be used on MS-SQL database. The optimizer of their database is probably one of the best and it can fix all the horrible EF queries launched. If you go for another database, like firebird, the optimizer is not that good and you will get a severe performancepenalty here.

Performance of Entity Framework is acceptable, but not when it involves tons of data. If you have to read hundreds or thousands of records, EF is not the way to go.

The designer of EF is really slow in big projects. Once you have are above 100 tables in your model… it takes minutes to rebuild. It is also very hard to find an “entity” inside the model. It even gets worse when you need to select a link.

The EF has some bugs that you will encounter and of which they say that it should never happen, but that it will be fixed in the next release. Google for some words in the error below, you’ll find workarounds and stuff. But no real solution. A relationship from the 'FK_PRJP_PRJPS_ID' AssociationSet is in the 'Deleted' state. Given multiplicity constraints, a corresponding 'ProjectPerson' must also in the 'Deleted' state.

Lazy loading and even enabling it will become your worst nightmare ever. It may look like it speeds up your process of development, but it fact you will lose all this time again with tweaking. Don’t enable lazy loading.

Proxy classes in the entity framework are awesome. I really like the idea and the theory. In reality, you’ll have exceptions in this “on the fly generated code” and there is nothing to debug or even see. You can’t even decompile because you only have an in memory assembly. Don’t enable proxy creation.

If you do enable lazy loading: be careful with navigational properties. Especially n-1 relations and especially those where you have a very low selectivity. Some unexpected things might happen.

Imagine you have a table of persons and a table of personstate. This state might be “Unkown”, “Active”, “Customer”, … When you create a new person it makes perfectly good sense to set the state link directly to “unknown”. Since EF will detect that the other part of the link is an m relation, it will make sure your link is correctly added to both ends. Both (Person.State == “Unknown” ) and PersonState(“Unknown”).Contains(Person)) will be true. This makes good sense, it is a bidirectional link and both ends should be correct. In order to have both sides correct, EF will “lazy”load the other side. Now imagine this on a big database where there are 4.000.000 persons with an unknown state.

There is no support for enumerations. If your database doesn’t support “bool” all your properties will be char or int inside your c# code. Unless you implement all of them manually, but then you can’t use them anymore in linq.

T4 templates are really awesome… but unfortunately you need them.

And all these things made me decide to put the whole project on hold for a month and a half (with 6 developers on it) and convert everything to llblGenpro.

I noticed that the "current" EF will be v1 for you. it is better than V4 (which is 2) because you won't have options like lazy loading or poco. the curve of making something in EF is not steep, but making something big is just not possible.

If you do have more questions, feel free to ask.

Alexander

Alexander,

Thank you very much! This exactly the type of feedback I was hoping for!