I just hava a question about what is the "recommended" framework to use for new projects now that LLBLGen supports more OR frameworks? nHiberante / Entity Framework / LLBLGen?

Also I want to know what is the future of the LLBLGen framework? Are you planning new features and keep developing the LLBLGen OR framework?

Best regards

washa wrote:

I just hava a question about what is the "recommended" framework to use for new projects now that LLBLGen supports more OR frameworks? nHiberante / Entity Framework / LLBLGen?

Whatever you want to use: each framework supported has strong points and weak points. If you want to use a POCO framework and like nhibernate, use that. If you want llblgen pro specific features, use that. The advantage with v3 is that you can switch at any time in the designer, so if you don't like EF after a while, switch. Of course your own code has to be converted, but at least your model is the same.

Also I want to know what is the future of the LLBLGen framework? Are you planning new features and keep developing the LLBLGen OR framework? Best regards

We have planned new features of our own framework, like multiple inheritance types in 1 hierarchy (it's currently 1 inheritance type in the whole hierarchy) and value type definition support. Our o/r mapper framework is and will be a first class citizen for our designer.

I was led to this thread because I think the original poster is asking a broader question. Or at least, I have a broader question: where can we get some real information on all this. I see tutorials that are from a version or two ago. The help files are there, of course, but they are rather... academic.

I'm trying to start coding in all this, but right-off I'm faced with choices that have consequences, but I don't have any information to help me make the right choice (ie, which framework to choose).

I think what would be helpful is a LLBLGen-centric description of the differences between the frameworks. Not just an abstract "supported"/"not supported" section. But tutorials that show the development of a single application in at least the four important frameworks (I'm assuming that EF v1 is probably not necessary).

For the place I am at, this would help kill many avians with a single igneous projectile. In other words, it could combine the benefits of learning the designer, creating a project from designer generated code, and deciding between the differences of these frameworks -- as well as learning application architecting with LLBLGen.

Thanks, Jeromeyers

psychlotron wrote:

I was led to this thread because I think the original poster is asking a broader question. Or at least, I have a broader question: where can we get some real information on all this. I see tutorials that are from a version or two ago. The help files are there, of course, but they are rather... academic.

It is really an academic topic, to be honest. To be able to make a proper decision about O/R mapping, you first have to know what it is.

Once you have that down, the obvious question then is of course: which framework to use? In all fairness: that really doesn't matter much: every framework we support can fetch entities from the database, save them back, allow you to query the database in any shape or form. Every framework has strong points and weak points, and you run into these in edge cases or specific cases, where you need features which are supported in one framework but not in the other.

If you just got started with O/R mapping, it all can be very complex and the list of stuff to consume and understand can be massive. This isn't helped by a big list of features which are supported by framework A but not in framework B. So instead, you should look at what you want to do instead. If you want to use Linq, nhibernate won't cut it. If you want POCO classes, LLBLGen Pro runtime framework isn't for you. If you want to consume multiple databases at once, linq to sql is not suitable.

With v3 there is 1 choice you don't have to make anymore: how you are going to maintain your project etc. Just create the entity model in v3 and pick a framework which does what you need/want, e.g. our own framework. Then generate code and start writing code. Not happy? Change the target framework in the designer and regenerate code and migrate your own code to that new framework.

The choice which framework to choose is something we can't make for you. It's the same as which of the many databases we support you should use: we can't tell you that: every database has strong points and weak points. There, it also comes down to what you want to do. Do you want live backups and no blocking of readers/writers? Oracle. Do you want to run .NET code inside the DB? Sql server. Embed a database? Firebird. Solid open source? Postgresql.

Again lots of choices, which are hard to make if you look at the things all these frameworks and databases have to offer: they all promise the world to you and life will never be the same without them. Instead, look at what you want to do, what do you need in your application, in the architecture of the software you're going to write? If that's bread 'n' butter stuff, like a 3 tier web app, nothing fancy so every framework will cut it. Do you need WCF RIA stuff, complex linq stuff, then things change.

By looking at what you need and what you want to do, you already start answering which target framework you need to choose. And nothing is lost if you pick the wrong one: just change the framework and re-generate code.

I'm trying to start coding in all this, but right-off I'm faced with choices that have consequences, but I don't have any information to help me make the right choice (ie, which framework to choose).

I think what would be helpful is a LLBLGen-centric description of the differences between the frameworks. Not just an abstract "supported"/"not supported" section. But tutorials that show the development of a single application in at least the four important frameworks (I'm assuming that EF v1 is probably not necessary).

True, we'll eventually get at that by migrating the examples we have on our website to other frameworks, but that IMHO won't answer the questions you have: it's very likely the examples we have won't match your application's needs 1:1: you need to look at what your application needs: do you use a fine grained aggregate based domain model with repositories or do you need deep graph fetching without repositories? Do you need authorization and auditing right inside the entities or do you not care about that? simple questions which reflect what you need in your own project and with that will show you what framework you need to pick.

I will just throw my 2 cents here as I was trying to answer (somewhat) the same question 5 years back. At the time, I was a fierce supporter of CSLA and honestly learned so much about n-tier development from applying Rocky's framework.

At the time Frans went under so much fire for going against the flow and daring to claim that dynamic SQL is better than SProcs (the famous "stored procedures are bad" draw him so much fire). Now, both of MS's frameworks adopt the same and everyone hails that as the next best thing since sliced bread !!!

The thing I discovered that it should not only be the architecture/framework you want to use but rather the development experience and cycle you will go through. Development by its very nature is about iterative change and LLBL promoted and helped in adopting to this continuous change cycle like no other framework did (and still is).

Bottom line, MS is obviously throwing all its might and weight behind its framework and that is EF's biggest advantage as that means a wealth of resources. LLBL's is much mature and rich and has the best support you can get in the .NET world.

Developers who have been using LLBL would not (willingly) be replacing their adopted ORM unless forced to do so by the decision makers and/or policy.

New ORM adopters need to consider their choice as a long term relation but the best advice one can get is the one Frans gave at the time and that was to keep an open mind and not to be a blind follower of the crowds.