I'm currently a licensed user of LLBLGen but lately I haven't been wanting to use it. I've been programming .net for years and started with creating objects that matched my database tables. (ie. User object for user table with properties matching fields and methods like AddNewUser, DeleteUser, etc). This seemed to work fine, but I was still new to the whole .net environment

The same guy who taught me .net and creating classes as objects had someone else introduce him to LLBLGen and he just loved it. I then gave it a try and thought it was insanely great. I used it on a few projects, using SelfServicing. It created all these files and I had no idea what they all really did. I would need a list of users in my app so I'd open up the UserEntity and go to the "Custom Entity Code" region and make a new function called GetUsers() returning a UserCollection. I'd keep adding functions I needed and scrolling all the way down the file every time to get to that Custom Entity Code region which was annoying.

I'd also make a change in the designer, generate the code, and it would for some reason break a bunch of things in my project. I also had the trouble when 2.0 came out that the generated code for 2.0 would break my project that had used 1.0.

I also was thinking all the code in all the files would really just slow down my projects. I needed to add a few new things to a couple projects I used it in and just went and made a utility class to execute SqlDataReaders and such to get what I needed done because I didn't want to mess with LLBLGen and needed to get the work done quickly.

I then talked to the guy that originally got my friend to use LLBLGen and he said I should use the Adapter model and create my own BL layer to hold the functions to retrieve the data I need, and make a UserManager class to AddUser and Delete user. This was better but it seemed like the code that I was adding in AddUser to interface with LLBLGen was pretty much the same as one I'd write with SQLHelper.ExecuteNonQuery to insert a user. If I had to type the same amount of code why don't I just remove the complexity of LLBLGen and just use the same code I've been doing...Adapters also removed the easy to code features of lazy loading.

Our company is even more starting to focus on software and in an effort to make sure I'm working smarter and not harder, I've spent the last few days doing hours of research on ORM's, different technologies, etc, trying to figure out the best way to create projects, etc.

My research has brought up that LLBLGen Pro is an awesome tool for apps, and have read that from many sources. The other big one I came up with was NHibernate. It seems with just adding your normal classes, a mapping file, and setting up the configuration, you can create objects and behaviors pretty easily. The other thing I like is there is not folders and folders of files of code, though I'm guessing all that code I see in LLBLGen is just compiled into the NHhibernate.dll. Anyway it just seems simpler. I've also found stuff like CSLA.Net and .NetTiers, but they seem really complicated.

Doing more research I've found there is a fundamental difference between software built on the domain model which has objects that encompass both fields and behaviors, and then the entity model where you have an entity of just data and have manager classes that handle the behaviours. I've been trying to decide which I like better. I like having a user object where I can call User.Add, User.Delete, etc. It's also nice on and Order orbject to call Order.Items and get a listing of items in that order. In programming web apps there are a lot of times where I need get a listing of fields comprising a few tables. I did accomplish this with TypedLists in LLBL. (Also I originally thought it was a great pain to have to make these defined typed lists in the designer everytime I needed a combined list of things), I then realized you can create these dynamically which seemed a little better. I'm not sure with NHibernate how I would get these custom lists.

So I'm curious what you all think about what I've talked about. I know I'm a "newb" at this stuff even though I've been programming for years. There is just so much out there it's hard to stay on top of it all. Right now I'm trying to decide on using NHibernate or LLBLGen for an upcoming project and have no clue which one I'd like to use. I have a feeling I just haven't learned enough about LLBLGen Pro, and I want to make sure I'm learning all I can about both products before deciding, as I'm really just a beginner in both of them.

Any help you can provide would be greatly appreciated!

Bob

Hi Bob

You do realise that you are only really going to get one answer from these forums don't you?

Obviously we're biased but LLBLGen has so much more to offer out of the box than NHibernate that it is difficult to know where to start. A generated LLBLGen project would give you a level of functionality that you could easily spend 2 weeks building for yourself in NHibernate (I know from experience, I was forced to attempt it at a previous job before I converted them) - and ours is tested and proven in thousands of production environments.

Support - have you tried asking this question (or any other) to NHibernate? What response did you get ? We offer 24/7 support by paid (no open source volunteers) experienced .Net developers with a 12 hour response time during the working week and 24 hours at the weekends. The level of support we offer is often given as reason for prefering LLBLGen over any of its competitors.

See http://weblogs.asp.net/meligy/archive/2009/10/31/which-orm-linq-to-sql-entity-framework-llblgen-nhibernate.aspx?CommentPosted=true#commentmessage for a happy customer.

If you have any more specific questions, feel free to come back to us.

Matt

Yes, I did realize that. I guess I'm sort of hoping for more information and the "right" way to use LLBLGen to do what I want, as well as answers to my specific questions in my massive post. I'm not saying NHibernate is better. I guess maybe I'll rephrase my questions and define some questions to help.

1. With the project I'm about to start it has data in SQL Server and MySQL, so I'm pretty sure I need to use the Adapter template. The code to do this seems very similar to code that I would right to retrieve data using a SQLDataReader. What a I gaining from LLBLGen? It seems like i'm writing just as much code...

2. Is there any way to duplicate doing things like Order.Items to return a collection of items with the Adapter method?

3. What is the reason you'd make a typed list in the designer vs one in the generated code?

4. Does anyone keep the data project LLBLGen creates out of their main solution and just use the compiled dll to keep things simple?

I think I'm going to look over the LLBL Gen manual as well as look over CSLA tonight. I see there is some kind of colaborative effort...I don't know much about CSLA but it sounds like I would like the business object-like approach.

Thanks for any and all information!

1. With the project I'm about to start it has data in SQL Server and MySQL, so I'm pretty sure I need to use the Adapter template. The code to do this seems very similar to code that I would right to retrieve data using a SQLDataReader. What a I gaining from LLBLGen? It seems like i'm writing just as much code...

LLBLGen Pro is an ORM, so the advantage is that it will supply you with classes/objects to use for your data manipulation, hence the "O" Object in the ORM. So if you want to use Objects as in Object Oriented... then LLBLGen Pro will give you the classes which map the Relational Model. These objects can be used as Low Level Business Layer (LLBL).

Also Maintainability is a great advantage, when your database schema changes, you get your generated classes updated with a couple of clicks and in few seconds.

As you get everything in objects, so you get Type Safety as well, no strings to manipulate in code. So no inline SQL to write or maintain.

1. Is there any way to duplicate doing things like Order.Items to return a collection of items with the Adapter method?

I don't understand what "duplicate doing things" mean in the context of your question.

1. What is the reason you'd make a typed list in the designer vs one in the generated code?

Same use a user may create a database view instead of constructing the query in code. You may call it pre-canned queries. And in the LLBLgen world, you may call it pre-canned Lists or views of data. If you don't have a reason to use, then don't use it.

1. Does anyone keep the data project LLBLGen creates out of their main solution and just use the compiled dll to keep things simple?

Some people do that, but I prefer to have all me projects in one solution. Helps a lot when re-generating the code, in order to build the entire solution once. This ensures everything is in Synch.

I'll add some additional remarks to the first post you made as an addition to the replies you already got.

bbutterworth wrote:

The same guy who taught me .net and creating classes as objects had someone else introduce him to LLBLGen and he just loved it. I then gave it a try and thought it was insanely great. I used it on a few projects, using SelfServicing. It created all these files and I had no idea what they all really did. I would need a list of users in my app so I'd open up the UserEntity and go to the "Custom Entity Code" region and make a new function called GetUsers() returning a UserCollection. I'd keep adding functions I needed and scrolling all the way down the file every time to get to that Custom Entity Code region which was annoying.

Yes, it's not a real solution. Partial classes are better, but it's the downside of using generated code: if you want to alter the generated code, you have a problem to solve, and if you don't like partial classes nor code regions, there's little left but to place your code outside the classes generated. In general that's fine though. It's just a different way of working.

I also was thinking all the code in all the files would really just slow down my projects.

In .NET, code is cheap, it's stored once in memory and doesn't get copied with every object instance, every object has a reference to the same code as every other instance of the same type. So if there's a lot of code, that doesn't matter.

I then talked to the guy that originally got my friend to use LLBLGen and he said I should use the Adapter model and create my own BL layer to hold the functions to retrieve the data I need, and make a UserManager class to AddUser and Delete user. This was better but it seemed like the code that I was adding in AddUser to interface with LLBLGen was pretty much the same as one I'd write with SQLHelper.ExecuteNonQuery to insert a user. If I had to type the same amount of code why don't I just remove the complexity of LLBLGen and just use the same code I've been doing...Adapters also removed the easy to code features of lazy loading.

Pure CRUD is simpler with an O/R mapper but the advantages are only visible when you save multiple entities, if you save 1 entity, it's pretty much the same, with the upside that it's easier to maintain (as it's typed).

The advantage of an O/R mapper comes with the services provided on top of the crud, e.g. validation, a query system, multiple ways of fetching data etc. etc.

My research has brought up that LLBLGen Pro is an awesome tool for apps, and have read that from many sources. The other big one I came up with was NHibernate. It seems with just adding your normal classes, a mapping file, and setting up the configuration, you can create objects and behaviors pretty easily. The other thing I like is there is not folders and folders of files of code, though I'm guessing all that code I see in LLBLGen is just compiled into the NHhibernate.dll. Anyway it just seems simpler. I've also found stuff like CSLA.Net and .NetTiers, but they seem really complicated.

NHibernate generates code at runtime, so it's basicly the same. They don't have a typed query system, and features we have are often up to you, like entity graph management and you have to write your classes and mappings by hand. This can be easy at first but a true nightmare after a while if the project grows and grows.

But in the end, it matters how you want to work. If you want to work with code first, classes and don't care about the db, llblgen pro doesn't match that system, the same as when you want to work with stored procedures, an O/R mapper won't match that way of working. The core goal of LLBLGen Pro is that you get a working, feature rich abstraction layer on your relational model in a very short period of time and you can directly focus on writing the code ON TOP of that, so the business logic. You don't have to spend any time on mappings, entity classes etc. as that's all plumbing.

Doing more research I've found there is a fundamental difference between software built on the domain model which has objects that encompass both fields and behaviors, and then the entity model where you have an entity of just data and have manager classes that handle the behaviours. I've been trying to decide which I like better.

Make no mistake, there's no difference. DDD doesn't dictate you what model you should use, people who like to hear themselves talking do, unfortunately. Placing the domain logic INSIDE the entities has downsides with respect to DDD which isn't easy to answer: if I want all 'Gold' customers, which are all customers who have 25 orders of > 500$, where should I place that logic? As it has to reach 2 aggregate roots, so it has to access two repositories (Customer and order). People like Fowler want people to believe that you have to place this logic inside an entity (or better: domain class) however aren't there when the developer runs in the obvious problem that the customer class then takes a dependency on the order repository (or the customer repository has a dependency on the order repository).

We think that there's no difference between adding an Order entity to Customer.Orders and calling a method Customer.AddOrder() which adds the order to the Orders collection, simply because both need a graph persister and graph validation system, and can't be done with repositories as you then would want to use an Order repository to add a new order to a customer, not a method on a domain class.

Software is already complicated enough, but some 'pattern evangelists' who try to tell developers to use pattern XYZ make things overly complicated. DDD is a great way of THINKING, of how to communicate with domain experts via an ubiquitous language (Evans e.a.).

So I'm curious what you all think about what I've talked about. I know I'm a "newb" at this stuff even though I've been programming for years. There is just so much out there it's hard to stay on top of it all. Right now I'm trying to decide on using NHibernate or LLBLGen for an upcoming project and have no clue which one I'd like to use. I have a feeling I just haven't learned enough about LLBLGen Pro, and I want to make sure I'm learning all I can about both products before deciding, as I'm really just a beginner in both of them.

If your client pays you for writing software for the client, does your client want you to work on plumbing code like entity classes and mapping files? For a db with 10 entities, that's not a lot of work, so it's likely OK. For a db of 100 tables, it's getting really complicated and time consuming (also to maintain it!)

HTH

Now searching through the forums I'm trying to figure out if Partial Classes or a Manager is a better way to go...?

What do you mean that an o/r mapper only has advantages when you save multiple entities, can you give me an example?

bbutterworth wrote:

Now searching through the forums I'm trying to figure out if Partial Classes or a Manager is a better way to go...?

Partial class is just a file that extends your entity class to write custom code. If you are using Adapter I would use partial classes to add custom properties to an entity, add field validations, etc. Partial classes must be on the same project, for instance in your DBGeneric generated project. You can use manager classes to separate and group your business logic. To facilitate the work you can download ManagerClasses templates on the client's section of the site.

bbutterworth wrote:

What do you mean that an o/r mapper only has advantages when you save multiple entities, can you give me an example?

Could you please explain that? or quote the words you want we elaborate more.

bbutterworth wrote:

What do you mean that an o/r mapper only has advantages when you save multiple entities, can you give me an example?

When you have an object with properties, and you want to save them, you can easily create an INSERT query from that, or an UPDATE query (albeit not really efficient) like you have already done as you described. This single entity persistence is also what home-grown frameworks can do, an o/r mapper OTOH provides more services when you want to save multiple entities (pk/fk syncing, ordering of saves etc.), complicated updates (flexible sql generation, filtering) are using inheritance etc. then an o/r mapper can help you without any effort from your part as you don't have to write any extra code.

I just wanted to illustrate the differences between a self-made object reader/writer vs. an o/r mapper

Thanks all for the abundence of information you have provided, it's been very valuable.

To get back into using LLBLGen I'm going to actually start a project for myself to make a sort of personal mint.com (one that will allow me to set my budget start and end dates). I'll use all the information provided here so again I think you. I'm definitely going to check out those manager templates as well.

I do think for this smaller personal project there really is no reason to use Adapter. One database and a smaller project for just myself seems to be perfect for SelfServicing, unless it's really beneficial that I start "practicing" using Adapter for upcoming work projects.

Thanks again!

Bob

Adapter is so much a better architecture for a project of any real size or complexity, and the overhead in using it is not really that much greater than for SelfServicing that I tend to use it all the time, whatever the size of the project.

YMMV of course, but I would say that if you are going to be using it eventually you may as well start sooner rather than later.

Matt

why is it so much better?

faster? easier? more scalable? more security?

bbutterworth wrote:

why is it so much better?

faster? easier? more scalable? more security?

I wouldn't call it 'better', it's just different. It has aspects Selfservicing doesn't like per-call catalog name overwriting, easier extensibility points etc. but it doesn't have lazy loading. That's also why we give a list of which situations suit each paradigm better. For example a distributed scenario requires adapter, however your test project would do fine with selfservicing.

bbutterworth wrote:

Doing more research I've found there is a fundamental difference between software built on the domain model which has objects that encompass both fields and behaviors, and then the entity model where you have an entity of just data and have manager classes that handle the behaviours. I've been trying to decide which I like better. I like having a user object where I can call User.Add, User.Delete, etc. It's also nice on and Order orbject to call Order.Items and get a listing of items in that order.

Bob,

Tools like NHibernate are nice if you want to work from a domain first, without concerning yourself with the database at all. You can do all your Test Driven Design and Domain Modeling in memory, and map to a database later. You can create very hefty domain objects that encapsulate all the logic you want. You can create your User.Add, User.Delete, and even User.ChangeMyselfToANonUser. How would that work? Who knows, and that's the problem.

It's a HUGE change to go from thinking about database tables first to thinking about domain objects. People who REALLY understand domain modeling get paid BIG bucks, but they are architects, not programmers. Would you feel comfortable developing an app entirely from objects ... without ever writing a database? If the answer is No (like it is for many of us), I'd say NHibernate is the wrong app for you. NHibernate on a "think database first" mindset is PAINFUL.

Encapsulating behavior and data in an object is hard (conceptually). You could do this in LLBL 2+ with self-servicing if you really wanted, but could end up going down the same confusing road as before. Plus, if you overuse lazy loading without really understanding it, your apps can suffer a huge performance penalty.

On the other hand, manager classes (or similarly a repository layer), allow you to define exactly what happens to an object. The entities still have relationships, you just need to know them beforehand via a prefetch path. So as long as you used a prefetch path for Items, you could enumerate Order.Items in your app.

The only thing I miss with Adapter is calculated fields. For example, an OrderEntity might have a NumItems and TotalPrice field. If I wanted to calculate an average price per item, in NHibernate I'd likely create a AveragePricePerItem property on the object that would perform the calculation. In LLBL, I'd create a method in my OrderRepository (or OrderManager depending on your approach/naming scheme) defined as GetAveragePricePerItem(OrderEntity order). With the Hibernate approach, the risk that another developer on my team creates their own calculation is minimal, but with the Repository/Manager it's far more likely that some developer will just throw the calculation in the Presentation layer's code behind, creating decentralized business logic.

why not add the calculated field to a partial class of the entity? It's then inside the entity, not overwritten by code generation and still just 1 implementation?