Some questions regarding serialization

[MABON]

In a tutorial from MSDN, I read about the serialization. It looks really powerful but I have some questions to define what is or is not the serialization.

Firstly, is that the serialization is right to associate with XML? By that I come from the fact that XML is finally a way to store information permanently after closing the software and then is that BDD can play the same role to serialize?

In fact, what I wonder is, for example, if you want to make software that manages customer and we want to have a BDD to store information in the long term.

What is the programming method to use? Is it must have a Client class with data members for all the information that is supposed to have a client in our application. And who would take over so the fields in the Customer table is in BDD ?

And when working on a client, it retrieves all the information in a new instance of class Customer. And in the end, we commend the information in the database?

Or you work directly in the database to query?

Is that the first option is the serialization itself or not? Is this is how we "must" program? Are there any mechanisms for just glue things in C#? Databinding?

[$tatic]

Firstly, is that the serialization is right to associate with XML? By that I come from the fact that XML is finally a way to store information permanently after closing the software and then is that BDD can play the same role to serialize?

No, there are several types of serialization: XML, JSON, binary, SOAP (XML-based even though it is a serialization protocol that) etc ...

What is the programming method to use? Is it must have a Client class with data members for all the information that is supposed to have a client in our application. And who would take over so the fields in the Customer table is in database ?

And when working on a client, it retrieves all the information in a new instance of class Customer. And in the end, we commend the information in the database?

Congratulations you just found the "good" method

You can either use the ORM as Nhibernate or LINQ to Entities (yes you can not see it as an ORM I know).

This type of framework, achieves a mapping from your SQL tables and your C# classes.

Basically every SQL table correspond Class C#.

When you change a property in your C# object and that you validate this change is reflected in BDD. You do not need to type in SQL, everything is transparent (but you can do if you want).

Otherwise, you can make your own Layer Data Access. You create your C# classes based on your tables.

You create a method that queries your GetClients BDD and transforms the result into a list of Class C# Client. Here you will have to type the SQL or stored procedure call.

Then we must also take care of the update, insert and delete

Or you work directly in the database to query?

That's what you do by creating your own Data Access (explained just above).

Personally I much prefer the ORM to query my database directly, but must also take into account performance.

LINQ to Entities example is very inefficient compared to the simple query based on stored procedures for example.

Is that the first option is the serialization itself or not?

No.

Is this is how we "must" program?

Use your own ORM mechanism or yes (there's even time of 50 approaches)

Are there any mechanisms for just glue things in C#? Databinding?

With WPF and Silverlight yes.

WPF/Silverlight + Linq to Entities is really great.

You bind your entities in your forms and when you change a field and through the interface that you run this update your BDD.

Otherwise, to return to the serialization, do not see it as a means of storing information. You saw yourself, the BDD are here for.

You can see the serialization as a means of temporary storage (offline or cache system for example) or as a means of transport.

I want to send an object to an application A to application B, I'm going to serialize, send and application B will recover and rebuild.

This is the principle of WebServices and remoting example.

[MABON]

Thank you for your reply.

If I understand correctly, what takes that to say no?

Namely:
- The user interface
- The layer of data access (DAL, Data Access Layer) => which can be developed either by hand or be a type Nhibernate Framework, LINQ to Entities
- The business layer (BLL: Business Logic Layer)

And business objects (Business Objects), what then are the classes that "reflect" the tables?

But I have a question that inevitably comes to mind if we copy our tables into objects, is what performance level, that always follows?

For example, if you have a listview that lists all clients, if there are 1000 customers, 1000 objects will be created in which customer data in the table have been repatriated.

Moreover, if each customer has a dozen bills, and it also retrieves data from each invoice in the Invoice type objects, each client has a list of invoice.
etc., we can add information related to customer ...

It can quickly begin to quantify, isn't it? Is this still viable?

Is that when you modify any of the information, the updater must immediately look into the database or write all data from a blow to the closure, even those that have not changed at once.

[$tatic]

And business objects (Business Objects), what then are the classes that "reflect" the tables?

That's exactly right.

For example, if you have a listview that lists all clients, if there are 1000 customers, 1000 objects will be created in which customer data in the table have been repatriated.

Moreover, if each customer has a dozen bills, and it also retrieves data from each invoice in the Invoice type objects, each client has a list of invoice.
etc., we can add information related to customer ...

This is where concepts such as lazy loading. In Lazy load mode, you only charge your customers. When you need the bills and only then you'll get the bills the client and him only.

Is that when you modify any of the information, the updater must immediately look into the database or write all data from a blow to the closure, even those that have not changed at once.

Here is what you like, or rather as your interface is doing. If you have an editing window of a client, the user expects that when he click on Save the changes are made.

Remember you do backups that customers have been changed.

In fact MNOs in each entity (instance of a class) has a state.

For example: Modified, Added, Deleted

When you call the Save method of your ORM, it lists all the objects which it is bound by its state and it makes the SQL statement that goes: Update for Modified, Added to Insert and Delete to Deleted.

If the user does not change a single client, the Save will only query your database (a single Update in this case).

Here the performance of LINQ to Entities must be improved. If you insert many elements that a little fishing.