Wayne, (I'm a newbie, who only trying the DEMO yet, so apologize if my questions seems silly)

I'm impressed with your Manager class, but i have some questions about it.

1. In the BL_EmpRec your return the properties from the EmployeesEntity class. Therefore the PL have to hold a reference to the LLBL dlls, so the PL developer can reach and use the class he/she like, and can bypass our business logic (or i missunderstud something?)

2. In the BL_EmpMan class you return a lot of datatable. But how would we return a collection of the BL_EmpRec, not to fill a custom collection manually? Here I think a solution like yours, ie. return an inherited LLBL employees collection, where the overriden Item return the EmployeesEntity as BL_EmpRec. But to do this, BL_EmpRec would implement an interface, what do you think?

In many posts in this forum i see the repeated questions:

How to share the built in rich functionality of the LLBLGenPro, but customize them with the minimum efforts so, that give to the clients, or to the PL developers only our business logic functionality, without the reliance on the LLBL libraries.

Because so many people search the above solution, i think whorts the effort to build a Northwind DEMO with true BL, that accomplishes the above principles.

(Or maybe it is useful only for newbies like me )

Is it in your plan Frans?

Thanks

Gabor

Gabor wrote:

Wayne, (I'm a newbie, who only trying the DEMO yet, so apologize if my questions seems silly)

I'm impressed with your Manager class, but i have some questions about it.

1. In the BL_EmpRec your return the properties from the EmployeesEntity class. Therefore the PL have to hold a reference to the LLBL dlls, so the PL developer can reach and use the class he/she like, and can bypass our business logic (or i missunderstud something?)

2. In the BL_EmpMan class you return a lot of datatable. But how would we return a collection of the BL_EmpRec, not to fill a custom collection manually? Here I think a solution like yours, ie. return an inherited LLBL employees collection, where the overriden Item return the EmployeesEntity as BL_EmpRec. But to do this, BL_EmpRec would implement an interface, what do you think?

In many posts in this forum i see the repeated questions:

How to share the built in rich functionality of the LLBLGenPro, but customize them with the minimum efforts so, that give to the clients, or to the PL developers only our business logic functionality, without the reliance on the LLBL libraries.

Because so many people search the above solution, i think whorts the effort to build a Northwind DEMO with true BL, that accomplishes the above principles.

There is no single solution to that question, that's the hard part. Some people want to use a BL layer with solely methods, others want to have different objects to pass around...

The most common reason why developers don't want to work with the libraries in higher layers is that they want to avoid having the GUI developers calling save methods while they have to call BL methods. This can be avoided using Adapter, which separates the two aspects of the code: entities and persistence logic. So you have in your GUI the reference to the Entities project (dbgeneric) and you have in your BL tier the reference to both (dbgeneric and db specific). The GUI then has to call teh BL methods to get things done and to get data from the database.

Really, I don't see why people would want to pass around objects of their own from BL to GUI which do exactly the same as the generated code (but less, as change tracking, relation awareness etc. isn't build in into the selfmade objects). Relying on an O/R mapper is not because of entities, it's because of the query language used.

Frans, thank you for the quick answer.

I'm a bit confused, how to build an application with your tool.

But as I understand now; I have to build a BLs that is an intermediere between the PL and generic adapter classes. The PL uses generic adapter class functionality via custom built BLs, that expose the business rules, and forward the entity/entities b/w PL and generic adapter classes, The generic adapter classes use the db specific adapter class for the db communication automatically.

Is it sounds right?

My other question is about template classes. Is there anywhere a more detailed information beside "basic concepts" in the manual, how to build and use them?

Thanks in advance

Gabor

Gabor wrote:

I'm a bit confused, how to build an application with your tool.

But as I understand now; I have to build a BLs that is an intermediere between the PL and generic adapter classes. The PL uses generic adapter class functionality via custom built BLs, that expose the business rules, and forward the entity/entities b/w PL and generic adapter classes, The generic adapter classes use the db specific adapter class for the db communication automatically.

Is it sounds right?

That's one way to do it. N-tier development is a global way of thinking without strict rules. So one team will opt for a BL tier with an api like: CustomerManager.CreateCustomer(...) CustomerManager.AddOrderToCustomer(CustomerID, OrderId, OrderDate etc... )

and another team will opt for a BL tier with an API like: CustomerManager.AddCustomer(CustomerEntity).

It's up to you want you want. I always say: you get the generated entity classes, you can add 2 types of BL to them: entity validators (using IEntityValidator interface implementaions) and field validators (using the validator classes being generated). The 3rd category of BL is often added to data-less manager classes.

You already have the entity classes, so you can opt to use them by default. If you don't want that for some reason, then you have to come up with an alternative. So first define why you wouldn't want to use them, and then look at if that's a valid reason to abandone them and what the alternatives are.

the BL tier should offer an API to the PL tier, so functionality of the BL tier is exposed in a generic way and can be reused between parts of teh PL tier. This is not related to LLBLGen Pro, but to n-tier development, and as there are no strict rules, it's up to you how this is realized

My other question is about template classes. Is there anywhere a more detailed information beside "basic concepts" in the manual, how to build and use them?

The SDK is only available to customers which describes how to write templates, how the templates work etc.

the manual is targeted at using the functionality provided, not how to alter that, as altering templates is an advanced topic often not used by a lot of customers. The concepts section in the manual is there to describe the concepts used in the generated code and which should answer the "Why " questions which arise when you look at the code generated.

Thanks Frans, it become more and more clear for me.

Would you tell me more about the dataless manager classes?

Thanks in advance

Gabor

Oh yes, the manager classes that manage the business processes. Thanks, it's time to begin working.

Gabor

Hi all

A question I still haven't resolved in my time as an LLBLGen user - should I pass LLBL entities to the PL or my own entities?

I'm passing back custom (although generated) businsess entities - just simple transport entities really, and datatables for collections. Now, the overhead of putting an LLBL entity into a custom entity is bothering me, as otis has said a number of times, why bother, when LLBLGen entities are good out of the box, and have a lot of functionality built it. Plus, if I passed back LLBL collections, then I get nice strongly typed collections - woo!

Well, the 2 main reasons I opted for custom entities and datatables are:

1. LLBL only maps database entities! Quite often I want to add extra properties to them, or even create a new entity loosely based on a couple of database entities. Adding properties to LLBL entities is possible, but not that straight forward. This is the single biggest reason.

2. I didn't want to bind the PL to LLBL gen entities. But I have decided that this is not such a bad thing, the chance of us dropping LLBLGen now is pretty null!

So, what do you all think? Does anyone else have similar issues with the need to pass non-database generated entities (or collections) back to the PL?

MattWoberts wrote:

Hi all

A question I still haven't resolved in my time as an LLBLGen user - should I pass LLBL entities to the PL or my own entities?

I pass the generated entities around. At least in the adapter model, they are more or less strictly data containers. If you are worried about division of labor (which you don't seem to be) you just don't let the gui or other layers reference the dbscpecific classes.

I'm in the don't make things more complicated that you have to (though no-ones perfect )

But that said, I usually don't have to add anything to the entities or extend the entities very often, so I don't really know what to suggest for that need.

I pass llblgen entities around too. If I ever need to extend them, I usually create a wrapper object that exposes the entity as a property and anthing else thats associated with whatever it is that I am doing, i usually expose that as a property as well.

And I definately agree with the "why code more than you need too approach."

Devildog74 wrote:

And I definately agree with the "why code more than you need too approach."

Yeah thats a no brainer. I also think your idea of just wrapping the object when you need to add more functionality is simple but effective. I'm thinking if I had to start the project off from start again, I'd consider this approach very carefully, and probably go with it...

MattWoberts wrote:

A question I still haven't resolved in my time as an LLBLGen user - should I pass LLBL entities to the PL or my own entities?

So do I pass entity objects in adapter scenario. They carry precious information (of what has been changed) which is necessary for my application, so mapping them to any other kind of data transfer objects would be an overhead.

I tried to expose them as interfaces (i.e. OrderEntity as IOrder with properties for example IList OrderDetails or ICustomer Customer). By doing this I would be able to control creation of objects in BL (or any layer beneath PL), and let PL be unaware of generated entity objects. All the necessary information would still be carried with objects. And it wouldn't put on any complication in implementation. But, unfortenately it didn't work due to EntityCollection not directly implementing IList. I haven't tried doing it in version 1.2004.2, maybe it works .

MattWoberts,

We also have decided to use custom business objects instead of the LLBLGen Pro entities. In cases where we want a quick list or set of data outside of a business object we just return a data set back to the client. One more advantage of not having LLBLGen Pro tightly coupled with your Presentation layer is that it gives us easy control in the future to move our business layer and data layer to seperate tiers in an SOA approach. We could easily pass lightweight business objects through a web service. In the future if we decide we want to use another vendor for our data access code or look into using LINQ then we can start moving new code in that direction. So far though, I have been pretty impressed with LLBL Gen Pro on this project.