Hi

New to this forum, quite newbie at .net and ADO.NET and kind of wondering what it is all about, really

We have an ERP-system written in a language that is not .net, and the plan is to, over time, port it over to C# (aside from that, we also have other database-projects, both Forms and Web). That's of course going to involve some serious database-programming, businessrules, validations and a whole lot of fun.

Can anyone explain to me why we should use LLBLGen over the datasets etc. that is already offered by ADO.NET? ( I guess it has something to do with "lighter"/"cheaper" objects and typing, but I don't really know)

If I have understood this whole thing correctly, LLBLGen generates entities that becomes the DAL-tier of the application. Do I need something between those entities and the GUI, or do the GUI bind directly to them? As I see it, I need some place (a class, eg. a class 'order', a class 'customer' etc.) to place business rules and validatons, so that I can re-use this code elsewehere in the application. Do I have to make some kind of "controller-objects/classes" or BO that plugs into the DAL? Is there any codegenerators/framework that makes these kind of things for me, or do I "simply" make it myself?

Would this be a good stack to use:

GUI (Forms, Web) | BusinessObjects (??) | DAL (LLBLGen) | DB (SQlServer)

Greatful for any replies.

your setup would work correctly. Depending on the simplicity of your project you can even combind your DAL/BLL layer and use: GUI (Win/ASP) DAL/BLL (LLBL) Database (SQL Server)

Out of the box LLBL entities have data binding attributes built in, so you can fetch an entity/collection of entities and bind them to a form/grid.

Entities have 3 types of validation built in. Field validation: validates when a field value changes. Entity validation: validates when a series of events are fires (before save, afterload, before delete...) Multiple entity validation: same as entity validation. Validation must be defined by your team since no two projects are the same. however all the hooks are in place with LLBL so you just supply the logic, not the framework.

With ASP.Net there is a LLBLDataSource control which allows you to declaratively program an entire form. very slick.

For complex operations you have typedlists (which are very simple to create), dynamic lists, which are like typedlisted, but delcared at runtime instead of design time. You can also use projection to fill custom BLL objects that are independent of LLBL. I haven't used these, but it appears to be a very powerful feature.

In terms of querying abilities the sky is the limit. LLBL has taken just about every concievable variation of sql statements and incorporated it into their product. I haven't come across any solutions in TSQL that I can't preform in LLBL.

The biggest hurdle I found was concepts and terminology. Concepts: I cam from a TSQL background, so now I had to translate what I know about scripts into OO. Terminology: I'm mostly self taught, so I didn't know the offical terms for what I was doing. I kept reading the forums and manuals and eventually I had my eurkia moment.

At first the reference manual may seem lacking, or incomplete. Just keep reading and re-reading... and posting questions on the forums. All the information is there, very consise. all the foundational (is that a word) information is there.

If there is **one **thing you should know about Solution Designs and LLBL it's this. They are a service oriented company. You can't beat the service... especially at this price. Hands down the best. No question is too simple, stupid, complex or rediculous. They are here to serve their customer base.

As to whether you need to buy this product. That is only a question you/your team can decide. What is your budget? How many users need the software? What is the cost of designing a DAL inhouse, rather than a 3rd party app? How complex/simple does the DAL need to be?

Once you purchase LLBL you then have access to the customer area of the website which includes downloads from the 3rd party section. The biggest feature here is Template Studio. This allows to you add/remove/modify the templates that create the DAL. Thus giving you even more control over how your BLL/DAL operate.

LLBL is a time saving tool; no question about that. The learning curve can take some time if your not use to the terminology, but once you learn it projects come together very quickly!

9ppel wrote:

Do I need something between those entities and the GUI, or do the GUI bind directly to them? As I see it, I need some place (a class, eg. a class 'order', a class 'customer' etc.) to place business rules and validatons, so that I can re-use this code elsewehere in the application.

As jmeckley said, there are many way to extends LLBL entities classes. You can use partial classes, inheritance, modify the templates...

And you can very easily bind entities to the GUI.

Thank you for your extensive reply. It really shows that you are really satisfied with this product.

jmeckley wrote:

your setup would work correctly. Depending on the simplicity of your project you can even combind your DAL/BLL layer and use: GUI (Win/ASP) DAL/BLL (LLBL) Database (SQL Server)

OK. If I want to add a BLL, are there any specific tools I should consider using? Or do ppl usually write these things themselves, from scratch?

Validation must be defined by your team since no two projects are the same. however all the hooks are in place with LLBL so you just supply the logic, not the framework.

OK, but in our ERP-system we have many validations and calculations that we want to happen wherever in our system a specific field is used. Like when an orderline is used, wherever in the system, and the user enters an amount in a foreign currency, that amount should automaticaly ble recalculated into the local currency and persisted into another field in the orderline table. An other example: whenever the user enters a customerID for an orderhead, a validation should occur, to secure that this customerID is a valid one.

These rules should be programmed only once, in e.g. an order class, a customer class etc, and not as an event in every program that class is used (at least, that's how I would like it to be )

Is this possible to achieve with LLBLGen, possibly in combination with another framework/product?

With ASP.Net there is a LLBLDataSource control which allows you to declaratively program an entire form. very slick.

Sounds promising

In terms of querying abilities the sky is the limit. LLBL has taken just about every concievable variation of sql statements and incorporated it into their product. I haven't come across any solutions in TSQL that I can't preform in LLBL.

Sounds even more promising!

If there is **one **thing you should know about Solution Designs and LLBL it's this. They are a service oriented company. You can't beat the service... especially at this price. Hands down the best. No question is too simple, stupid, complex or rediculous. They are here to serve their customer base.

I've been reading around a little in the forums, and this is exactly the impression I've got to. About that "no question to stupid"....well, just give me some time to get started here....

As to whether you need to buy this product. That is only a question you/your team can decide. How complex/simple does the DAL need to be?

Well, as I mentioned further up, we are used to have our validation rules and business rules in one place, a class. In an ERP-system there is obviously a lot of calculations, validatons an conditional updating, like updating stock numbers when an order has been placed, calculating amounts in currencies, calculating discounts etc.

9ppel wrote:

OK. If I want to add a BLL, are there any specific tools I should consider using? Or do ppl usually write these things themselves, from scratch?

I have seen posting about a CLSA BLL framework built atop LLBL. I think the project is either free or open source. I think most people build their own business classes.

9ppel wrote:

OK, but in our ERP-system we have many validations and calculations that we want to happen wherever in our system a specific field is used. Like when an orderline is used, wherever in the system, and the user enters an amount in a foreign currency, that amount should automaticaly ble recalculated into the local currency and persisted into another field in the orderline table. An other example: whenever the user enters a customerID for an orderhead, a validation should occur, to secure that this customerID is a valid one.

These rules should be programmed only once, in e.g. an order class, a customer class etc, and not as an event in every program that class is used (at least, that's how I would like it to be )

Is this possible to achieve with LLBLGen, possibly in combination with another framework/product?

You could inject your current logic into the LLB validators. Here is a simple example for field validation

public bool ValidateFieldValue(int fieldIndex, IEntity involvedEntity, object value)
{
    bool toReturn = true;
    switch((MyEnityFieldIndex)fieldIndex)
    {
          case MyEntity.MyField1:
                     //insert my logic here, compare value to whatever value it should be
                     toReturn = T/F; //or throw ORMEntityValidationException.
                     break;
          case MyEntity.MyField2:
                     .....
                     break;
     }
     return toReturn;
}

if you return false the field value is not updated. If you throw an execption you code must handel the execption once thrown.

Entity validation example:

public void ValidateBeforeSave(IEntity involvedEntity)
{
        //inject your current logic here
        //declare your current validation object (pass values compare)
        If valid do nothing
        If NOT valid throw ORMEntityValidationException
}

Validation can be it's own seperate class, or it can be embedded direclty in the entity. I prefer my validation to be a seperate object that is injected when the object is created. This way if I ever wanted different validation objects (for whatever reason) I can override the default validator when I instantiate the entity.