Hi,

Lets say I want to update a product. I have form elements in a web page to gather the data. When the user presses submit, should the values of the form elements be passed to the BLL and then inside there assigned to a product entity instance or should the assignments take place in the web page and then the product entity passed to the BLL to be operated on?

Cheers,

I.

Whatever suits you more.

If you want to abstract the EntityClasses from the UI -> then pass the parameters as is or in a structure/simple class (better if you have many parameters to pass).

If you the weight of the Entity Classes is not a problem, and there is no need to hide them from the UI, then use them.

Ian wrote:

Lets say I want to update a product. I have form elements in a web page to gather the data. When the user presses submit, should the values of the form elements be passed to the BLL and then inside there assigned to a product entity instance or should the assignments take place in the web page and then the product entity passed to the BLL to be operated on?

As the previous message says, it depends. But, I think you are going to add alot of code if you go with the second method.

I prefer to see the Entity objects be used in all three layers. This is the data container that you have choosen to use, you might as well use it.

With a web form you might also want to cache the Entity in the page so that you can use concurency checking, if that is important to you.

BOb

I agree with the idea of using the entity classes wherever possible, as to do otherwise would require you to create a whole new set of objects that were, basically, duplicates of the generated entities in the first place.

The one problem with this approach, however, is the temptation to treat the entity classes as having an instrinsic meaning or purpose. It is instinctive to want to aggregate your process's data in an entity hierarchy and pass it to a service for execution, but the entity classes themselves have no indication of their use for any particular purpose, in this case as the minimum set of data required to execute the process. There is no way to know which data is required in order to meet the service's requirements as the entities are simply Data Transfer Objects, no more.

From this perspective, it makes sense to use the entities as DTOs whenever possible, usually intra-layer or between closely related layers (UI and process/state), but construct Business Documents or Messages that defines exactly which data is required to successfully execute the final process when sending data to your business layer, or any other explicit boundary Jeff...

I agree with what Jeff said. We use our entities through all three layers. However, we have run into the situation Jeff describes where it isn't entirely clear based on the entities going into a method what is required. We have chosen to move forward with passing entities for the meantime as opposed to implementing a more robust parameter/messaging architecture to call the BL methods.

mattsmith321 wrote:

I agree with what Jeff said. We use our entities through all three layers. However, we have run into the situation Jeff describes where it isn't entirely clear based on the entities going into a method what is required. We have chosen to move forward with passing entities for the meantime as opposed to implementing a more robust parameter/messaging architecture to call the BL methods.

My quess is your talking about when you have an Business Object the models a process or task rather than something that is strictly an entity.

In this case I think you should be creating a Business Object (entity) for the process. Once example we have in our Application would be Payroll process. This aggregates the use of alot of entities. So, the the PayrollProcess object is created. It contains methods to execute the payroll. Of course, it passes the reponsiblities to other object. For example, the EarningEntity has a method to calculate itself, but it is the PayrollProcess object that sums all the regular earnings and stores them in the PayrollTransactionEntity object.

BOb

pilotboba wrote:

mattsmith321 wrote:

I agree with what Jeff said. We use our entities through all three layers. However, we have run into the situation Jeff describes where it isn't entirely clear based on the entities going into a method what is required. We have chosen to move forward with passing entities for the meantime as opposed to implementing a more robust parameter/messaging architecture to call the BL methods.

My quess is your talking about when you have an Business Object the models a process or task rather than something that is strictly an entity.

In this case I think you should be creating a Business Object (entity) for the process. Once example we have in our Application would be Payroll process. This aggregates the use of alot of entities. So, the the PayrollProcess object is created. It contains methods to execute the payroll. Of course, it passes the reponsiblities to other object. For example, the EarningEntity has a method to calculate itself, but it is the PayrollProcess object that sums all the regular earnings and stores them in the PayrollTransactionEntity object.

BOb

Yes, but to clarify, the input parameters to your business logic layer/service may not necessarily be the actual Business Objects. In a disconnected scenario it doesn't make sense to assign behavior to these input parameters (and thus create a Business Object) as the context to perform the behaviors (such as data fetches) may not be available outside of the service boundary. It's not to say that behavior can't be assigned to them; it's just that, when dealing with an explicit service boundary, you're primarily talking about instructions and instructions mean data in a specific format/semantic purpose/validation context. I think the response to the OP is that the LLBL-generated entities are purely data containers with no such indications and thus may not be suitable for passing to BL when talking about distributed/disconnected scenarios.

Jeff...

jeffreygg wrote:

Yes, but to clarify, the input parameters to your business logic layer/service may not necessarily be the actual Business Objects.

Agreed.

jeffreygg wrote:

The one problem with this approach, however, is the temptation to treat the entity classes as having an instrinsic meaning or purpose. It is instinctive to want to aggregate your process's data in an entity hierarchy and pass it to a service for execution, but the entity classes themselves have no indication of their use for any particular purpose, in this case as the minimum set of data required to execute the process. There is no way to know which data is required in order to meet the service's requirements as the entities are simply Data Transfer Objects, no more.

I'm making these decisions right now, so I'm glad to have found this thread. I'm curious to know what you do then, if you do not pass the entities back to the BL? Maybe I'm not understanding your post correctly, but let me present a scenario and you tell me what you see as potential pitfalls. Let's say we have a datagrid whose DataSource is an EntityCollection of EmployeesEntity. The user edits the employee's last name and clicks update in the grid. How would you go about saving that change? Would you call a single method in your BLL that is "SaveEntityCollectionChanges(myEntityCollection)" or would you simply call the DataAccessAdapter.SaveEntityCollection(myEntityCollection) inside of your UI? Or would you do something else? Both of my ideas feel like I'm missing something, so clue me in.

In the Examples section of the LLBLGen website, there is a port of the MS Petshop application ("MS Petshop port to LLBLGen Pro code. (C#, Adapter, ASP.NET)"). I know Frans has said that there are quite a few things he would change with it, but it shows very clearly how the UI/PL interfaces with the BL and finally the DAL using Manager classes, which many people find a great approach to creating the BL (including myself). It might be very helpful to download the code, start with a screen in the PL, and follow the flow down through the layers.

For those just starting out, I think it is a great sample.

NickD wrote:

jeffreygg wrote:

The one problem with this approach, however, is the temptation to treat the entity classes as having an instrinsic meaning or purpose. It is instinctive to want to aggregate your process's data in an entity hierarchy and pass it to a service for execution, but the entity classes themselves have no indication of their use for any particular purpose, in this case as the minimum set of data required to execute the process. There is no way to know which data is required in order to meet the service's requirements as the entities are simply Data Transfer Objects, no more.

I'm making these decisions right now, so I'm glad to have found this thread. I'm curious to know what you do then, if you do not pass the entities back to the BL? Maybe I'm not understanding your post correctly, but let me present a scenario and you tell me what you see as potential pitfalls. Let's say we have a datagrid whose DataSource is an EntityCollection of EmployeesEntity. The user edits the employee's last name and clicks update in the grid. How would you go about saving that change? Would you call a single method in your BLL that is "SaveEntityCollectionChanges(myEntityCollection)" or would you simply call the DataAccessAdapter.SaveEntityCollection(myEntityCollection) inside of your UI? Or would you do something else? Both of my ideas feel like I'm missing something, so clue me in.

Well, in order to validate properly at the business layer, you need to have endpoints that have a semantic meaning. For example, in your case, you might expose a "SaveEmployeesBulk()" method. From this perspective, the argument passed in is important as it is within the the user's expectations are set as to what's required. In the save employees case, this may not be important, but consider a different scenario:

Purchase Orders have line items which reference vendor's catalog items which reference internal catalog items. If I have a "SavePO" method that takes in a PurchaseOrderEntity, which possibly contains within it's object graph the PO Line Items, the Vendor Items, and the Internal Items, how do I know what's being communicated to me if the PurchaseOrder.POLineItems collection is empty? Does that mean there are no changes? Does it mean that all of the line items should be deleted? How do I validate that object graph, especially the PO line items, when there is no inherent, intrinsic meaning to it as it's just simply a DTO? How does the caller know what to populate the Purchase Order with?

As a means of communicating data, the entities are beautiful; as a means of communicating intention or meaning they suck, because that's not what they were intended for.

All of that being said, however, if you're a single developer or on a small team with good communication, this all may be unimportant. However, if reuse is important at the business layer level you may want to reconsider using entities to communicate to your business layer.

Jeff...

Scotty - Thanks, I'll take a look at that.

Jeffrey - Thanks for your insightful response. Definitely some good stuff to chew on.