Hi all,

I have tried to find, for two weeks, information on this subject but not find enought pros/cons to make me a clear opinion on this subject.

I want to know if you prefer to pass value or object between from your UI to your business layer.

Value :

public class Customer
   Save(firstName as string, lastName as string, city as string)
end class

In this case the UI create the Customer manager and pass to it value from control.

Object :

public class Customer
   Save(customer as CustomerEntity)
end class

In this case the UI create the Customer manager, create a CustomerEntity, set the properties on the CustomerEntity with value from control and pass to Customer manager the entity.

I started to question me when the HnD source code has been released. The majority of the business takes value as parameters and not entity.

Thanks for your help

Hi Matlaf,

Gosh I would have voted for the 2nd way every time! Seems much more stable and maintainable to change code that fills out the properties of the entity rather than changing method signatures (ugh)

I will be interested to hear others responses.

Sean

the entities have the data binding logic built into them as well... I think, from reading other posts. If you didn't want to pass the actual entity, or modify signatures, you could generate DTO's which mimic the entities field properties. However this add's complexity to the system which may (not) be warrented.

Gosh I would have voted for the 2nd way every time! Seems much more stable and maintainable to change code that fills out the properties of the entity rather than changing method signatures (ugh)

Agree with this. I think it's a pros for solution 2. But it's not enough to convince me to choose this one.

the entities have the data binding logic built into them as well...

I think I do not specify I have no problem to use entity and entity collection in the UI layer (Ex. for databinding).

My concern is more when I return the value from the UI to my manager (Business).

Does the UI know or have to know how to use or construct model entity or is this the responsibility of the business layer? If it "can" know that, I would choose solution 2. If it's better the UI can't know how to construct entity I would choose solution 1.

It's there I can't decide me which is the better solution.

What's your idea about this?

Also, can someone (like Frans) can explain why, in the HnD, the majority of the data pass from the UI to the Business is simple type?

Thanks all.

matlaf wrote:

Also, can someone (like Frans) can explain why, in the HnD, the majority of the data pass from the UI to the Business is simple type? Thanks all.

in HnD a lot of the data needed by the UI is readonly data, and the sets used are also sometimes containing aggregated data (e.g. # of posts, last date of post etc.). The most efficient way to retrieve these sets is via a typedlist/dynamic list.

When entities have to be manipulated, created or deleted, we use entities instead.

So we used per situation what's best for that situation. As llblgen pro can handle everything, we don't need to branch out to something else for the dyn. lists for example, one of the main reasons why llblgen pro has typed/dyn. lists

I think I don't clearly expressed my question.

My question is more general than the LLBLGEN framework. From the Business layer to the UI I have no problem with the idea we can transfer entity, typedlist, custom class, typed view. My concern is when I want to resend data from the UI to the Business.

Example from HnD:

        public static int CreateNewMessageInThread(int threadID, int userID, string   
                                  messageText, string messageAsHTML, string userIDIPAddress, 
          string messageAsXML, bool subscribeToThread, 
                                 string threadUpdatedNotificationTemplate, 
                                 Dictionary<string,string> emailData,
        bool sendReplyNotifications)

Why you want to pass all simple value from your entity as parameter of CreateNewMessageInThread and not pass an entity itself created in the UI?

It's here I have difficulty to know which solution is better. I know the better solution can differ depending of the situation but I want to evaluate the pros/cons.

If someone else have opinion, do not hesitate to give it.

Thanks all

Well let me give my 2 cents...hope this helps...sounds like you know most of this stuff already but your just making sure.

The only reason I would ever write a method signature like that is if I didn't want the consumer of the method to have to know or mess with building the object themselves instead. It would be unreasonable to expect consumers of your object model to all learn LLBLGen so they can create entities and use your business logic. Also the external consumers would have to have your DLL to build the objects to pass in anyway. So that leaves 3 options:

1 - Pass in xml and just agree on schema 2 - Pass in simple types and use overloads for future enhancements 3 - Wrap LLBLGen objects with simpler to use factory pattern business objects that outsiders can quickly learn and use

Option 1 & 2 would work well in an environment where unknown public is using your business layer

Option 3 would work with well known business partners who don't mind getting your BL wrapper dll and a little learning curve.

So if you are publishing your methods to outside customers out there in public I would say you would want to use 1 or 2...otherwise go with 3 like we did.

I chose option 3 and wrapped my objects with CSLA framework. People mostly understand CRUD methods and the broken rules automatically preventing saving bad data is an awesome feature too.

By the way don't I recognize your name from the CSLA forums?

Sean