How can I test the following + advice needed

Hi,
I am building a small .net framework for some of my applications
I could have used already made ones like the excellent CSLA but I wanted
to write my own as to better understand few issues.

I understand that everything is a trade off and nothing is set in stone
however could somebody clarify the following:

When I pass an object between layers/tiers to avoid chatty object
I place the word serializable on top.

Does this kick in only when is processing an out of process component
How can I test that my object is serializing and not being chatty

I can pass the object between tiers 2 ways

AddCustomer(int id,string Name,string Surname ,etc...)
or

CustomerInfo customer=CustomerInfo.NewCustomer();
Customer.ID=txtID.Text;
Customer.Name=txtName.Text;
Customer.Surname=txtSurname.Text ;

addCustomer(customer);

Which way is better considering that CustomerInfo is serializable

Is there a limit on the number of argument that can be passed in a function
Am I creating a chatty object Ideally I would pass addCustomer(customer)
How can test that my object is stateless

Would say that there is no need to add a businessFacade to decouple
between UI and BusinessLogic and it's only needed when using Services

Thanks in advance

.NET Development8

1. The second method is better because you will not have to break the interface if you change the structure of your object. For example if you add a WebSite property your CustomerInfo object, you will have to add a new parameter to your AddCustomer that accepts params, whereas you can call your addCustomer method without any chance to the signature. The second method might be a bit heavier as it is passing more information on the wire, but it's probably worth it for the maintainability tradeoff.

2. That's an interesting question. Serialized objects don't have to be stateless, as serialization maintains state across the wire. Now if there is some heavy data that you don't want to be passed accross the wire, you can use attributes to mark it as non-serializable. For exampley our object might contain a large collection that you don't want passed accross the wire. In this case you would mark those properties / fields as non-serializable. Then if you needed the data again, you would requery after the object is deserialized to get the data.

3. Need is open to argument. Advantage of a facade is that you can change your business classes implementation without affecting the client reference. A facade certainly is advantageous in a SOA model. Outside of that it's open to debate. Another option instead of a facade is to use a Factory pattern and return an object that implements an interface. This way your UI references an interface rather than a concrete class. Then you can change the implementation in the same way.

First of all thanks for your reply.

1.I will implement passing the object rather than args as it will not break the interface.

2 I am a WindowsForm guy moving to asp.net and I have always read that you should pass a stateless object.I might have done it already.Is there a quick example somewhere that shows you that.At least I will know what makes a stateless object

3. "Another option instead of a facade is to use a Factory pattern and return an object that implements an interface"

Do you mean something like:

IDAL Class Library
-----------------
public interface IEmployee<T>

{

T GetEmployee(int id);

}

DataObject Factory
------------------
EmployeeDto IEmployee<EmployeeDto>.GetEmployee(int id)
{
DataSet ds = GetEmployeeDataset(id);
DataRow row = ds.Tables[0].Rows[0];

return ConvertToObjectDTO(row);
}

Business Library
-----------------
private static readonly IEmployee<EmployeeBaseDto> dal = new EmployeeFactoryDao();
public static EmployeeBaseDto GetEmployee(int id)
{
return dal.GetEmployee(id);
}

I use a Structure as DataTransfer Object as it's lightweight and pass it around between the layers.

Thanks again for your reply

1. Using the DTO is probably the best bet rather than the actual domain object as depending on how intertwined the relationships are for your object, it might be difficult to pass just the objects needed for the transaction on the remote side.

2. Stateful objects use up resources. In the COM world it's a bigger deal because when you pass an object you are basically setting up a remote proxy to which all calls are then being marshalled. If that object contains other objects, then they are being marshalled as well. In .NET though you can pass objects by value (i.e. serialization), in which case there is less to worry about. In the ASP world state was a big problem because if you created stateful objects that you stored for example in the ASP session you would be using up server resources. The importance of having stateless objects in that model is so that you can instantiate an object for a moment in time, and the release the object immediately thereby returning resources back. Instead of storing the object in the session, you store the data for the object. You then have a method that you can use (constructor) so that when you instantiate an object you can pass it the state directly to reconstruct the object.

In ASP.NET though you have many more options relating to session state, as session can either be inprocess, or stored externally in a separate process or in a database. If you are using inproc session you still have to be wary of putting objects (especially heavy objects) in the session as they will consume resources. However if you use a session state of say StateServer or SQLServer then the only objects allowed in the session will be those that are serializable. This means that the objects are serialized out of the main web server's process and are not consuming it's resources. In these cases you still want to be cautious about how much you serialize (i.e. related objects / child collections) as if you aren't careful you'll end up serializing your entire object graph, which could consume the memory of your caching server and be a signficant performance hit for each request.

3. It depends on for what reason you were intending to use the facade, I wasn't sure as to why you need one in your case. If you have a complex set of interactions in order to complete an operation, then you should have a facade to ensure that all those interactions are shielded from the caller. As far as having a facade for Services, a service itself is (or at least should be) a facacde. The service should not be a 1 to 1 representation of the internal API. The service should be an abstraction and internally handle mapping the data passed within the service message to the domain model and vice versa. This way you can change your internal implementation over time without affecting the service interface itself.

As to your example I am not clear exactly what you are trying to do. It looks like having a facade for your GetEmployee method makes sense as there are several steps involved with getting the employee and creating the DTO that you don't want the client to have to be concerned with. As to the generics, are you trying to support multiple Employee factory implementations through the IEmployee<T> interface Are you trying to support multiple DTO implementations as well as I see EmployeeDto and EmployeeBaseDto Can you clarify your intent here Where does the AddCustomer method that you mentioned in the original post fit in to this

I am trying to write a framework not as involved as the CSLA of Rockford Lohkta but something
on the way there.
My problem has been that there are not many books or MSDN pratical examples (solution with projects)
to that point I am reiventing the wheel.

Is PetShop 4 a good example of how a framework could be written Something to start with.

1)I am going to pass DTO object and very lightweight to communicate between tiers.

2)Stateless object.Your explanation is very good .However do you have a pratical example I can download
where I see how you pass a stateless object between tiers.

3)I used generics in my interface but there was no need .sorry for confusing you.
4) Business Facade,in all the docs I have read it's mentioned that it's good practise
for webServices to go via Business Facade and I was wondering if it would make sense to
abstract the ui from the Business Logic.
5)The addCustomer Method was used as an example to clarify if it's better to pass arguments
like "AddCustomer(name,surname etc) " or pass the object like "AddCustomer(customerDTo)"

6)Is it better to have a business Layer composed of many object Library

EG EmployeeBiz (ClassLibrary),CustomerBiz(ClassLibrary) or

have just one Project (BusinessObjects) with folders and classes in there

My framework would be :
UI ---> calls Business Facade Layer
Business Facade Layer -> BusinessObjects Layer
validates and comeback to the Business Facade Layer

Business Facade Layer -> DataObjects
Gets a DTO object
DataObjects -> Sql Server
Returns a Dto object to the business Facade
BusinessFacade -> BusinessObjects
Validates and check the Business Object for rules etc…and returns to business Facade

BusinessFacade -> UI

I am willing to send a solution with 4 methods just to confirm if they way i am passing objects
between tiers is correct or not.

Again I apologize for the lenght of this post and the questions i am asking .I would be grateful of any replies.