Devildog74 wrote:

You are not comparing apples to apples. You sample is using a typed object, i.e. an entity, that probably has relations, and comparing it to an untyped dataset,i.e. no relations or additional schema for the dependent objects.

Sure, an untyped DS will probably be smaller than a typed entity with relations. One of the key points of the original thread was that the developer wanted strong typing, so that they could say collection.item(0).FirstName.

Using a dataset to say dataset1.tables(0).rows(0).item("FirstName").ToString, is no more intuitive than using collection.item(0).GetCurrentFieldValue(EmployeeFieldIndex.FirstName)

Ok so I'll try to make a typed dataset and check again the size. But I don't think it'll be a lot more than in my test, typed dataset are almost dataset with a better schema. And you're right, my entity have a lot of relations, but none are loaded.

If you want, I can send you the test case that I wrote that uses the binary serialization object to serialize a dataset and a regular object for MSMQ transport. It might save you some time in your sample.

I, for one, would be interested in your test results.

The use of EntityCollections within my PL has been a real productivity boost.

My biggest dilemma has been in segmenting my BL properly. Specifically in the area of not duplicating BL code when you have tables that overlap into other tables that perform different types of Business Logic. Any suggestions on that would be helpful.

I may be the fish (at least my wife tells me I smell like one sometimes), but DevilDog, your the man, uh, Dog

My the force of the EntityCollections be with you

Fishy

Fishy you sound like a StarWars Nerd - Arn't we All!

Aye, but I like to balance it with Strange Brew (Mckensy brothers) humor.

So I guess that should have been "Use the Force you hoser - take off!"

I've not a lot of time to make the test But I've look at the xml generated by the writeXML function

It take a lot of place because : 1) It generate a lot of lines for empty collection, so an entity with a lot of relations will always be bigger than the same entity in a typed dataset. Why unfetched collection are serialized in XML ? I don't see any utility, maybe you can tell me some (Otis?). 2) It generate type for each property, for example :

<IsReadOnly Type="System.Boolean">False</IsReadOnly>

why not only

<IsReadOnly>False</IsReadOnly>

Why not find the type by reflection ? all informations are allready present in the assembly, on the server & client side, I don't see why it have to be included in the serialization.

Devildog74 wrote:

If you want, I can send you the test case that I wrote that uses the binary serialization object to serialize a dataset and a regular object for MSMQ transport. It might save you some time in your sample.

I just see you're talking about binary serialization. I'm talking about XML serialization ...

Fabrice wrote:

Devildog74 wrote:

If you want, I can send you the test case that I wrote that uses the binary serialization object to serialize a dataset and a regular object for MSMQ transport. It might save you some time in your sample.

I just see you're talking about binary serialization. I'm talking about XML serialization ...

I always try to use binary serialization because it takes less space to serialize something to binary than compared to soap or xml.

Devildog74 wrote:

I always try to use binary serialization because it takes less space to serialize something to binary than compared to soap or xml.

Yes you're right, binary is always smaller. But I'm working with webservices so I have to use XML.

Hi All

Propably a stupid question... How do i retreived a datatable or datareader or dataset from a collection? - I am sure i saw it somewhere - Sure i used it before aswell - but can't find it now.

Hi Otis - any solution for my question above?

Selfservicing has a method for that (GetMultiAsDatatable). With adapter you should use FetchTypedList(), see: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=462

(I'm not reading everything in this forum, however I'd like to comment on this entry )

Fabrice wrote:

I've not a lot of time to make the test But I've look at the xml generated by the writeXML function It take a lot of place because : 1) It generate a lot of lines for empty collection, so an entity with a lot of relations will always be bigger than the same entity in a typed dataset. Why unfetched collection are serialized in XML ? I don't see any utility, maybe you can tell me some (Otis?).

Because the XML can now be used in generic XML processing logic which always works on collections, without having different codepaths for empty and not empty collections.

2) It generate type for each property, for example :

<IsReadOnly Type="System.Boolean">False</IsReadOnly>

why not only

<IsReadOnly>False</IsReadOnly>

Why not find the type by reflection ? all informations are allready present in the assembly, on the server & client side, I don't see why it have to be included in the serialization.

Because when you process the XML further, for example first via an XSL template and then again with an XML consuming piece of code, you still know what the type is of the data of a tag. The XML is usable without falling back on the classes. That was the intention, and that's why the XML is somewhat verbose for some purposes, and full of useful information for other purposes.

GetMultiAsDatatable - knew there was something.

I just regen the DAL - There is no GetMultiAsDatatable in my Selfserv collections?

What version of LLBLGen is that in - I use 1.0.2003 Final April 30?

I must be missing something.

EmployeesCollection Employees = new EmployeesCollection();
Employees.??????????

Only have the following:

Employees.GetMulti Employees.GetMultiManyToManyUsingCustomersEntitiesForOrders Employees.GetMultiManyToManyUsingShipViaShippersEntitiesForOrders Employees.GetMultiManyToManyUsingTerritoriesEntitiesForEmployeeTerritories Employees.GetMultiManyToOne

I am doing an example on how to implement a BL with LLBLGen - using Northwind database. - Had a few requests. - Not enough hours in a day!

Still can't find it.

Downloaded the latest Tempates & Tasperformers for SQLServer and C# (Templates_SqlServer_04302004.zip, Taskperformers_SD_04302004.zip) - Just incase i was missing an update - GetMultiAsDatatable does not exist in the templates?

Am i going MAD?

It's a static method, as it doesn't return nor fill a collection object Every collection has it, trust me

Found it! - knew i saw it before

The Key =

It's a static method,

Not like

EmployeesCollection Employees = new EmployeesCollection();
DT = Employees.GetMultiAsDatatable

but like

DT = EmployeesCollection.GetMultiAsDatatable

Otis wrote:

Because when you process the XML further, for example first via an XSL template and then again with an XML consuming piece of code, you still know what the type is of the data of a tag. The XML is usable without falling back on the classes. That was the intention, and that's why the XML is somewhat verbose for some purposes, and full of useful information for other purposes.

Ok I understand (and agree, didn't think xml can be used for any other stuff than deserialisation) Could be a cool feature to add a property on entities to specify an xmlGenerator, so anyone can modify xml output easily (and put generator available in 3rd party section ), even dynamically if xml can be consumed by different side.

It's not that easy

The ReadXml() methods are virtual (as are the WriteXml()), so they can be overriden and other Xml producers can be implemented, it is hard to plugin different xml serializer code as the Xml generation is not that simple as it might look (for example the code handles cyclic references, something Microsoft's XML serializer is not able to deal with, which requires 2 passes when you read XML).

The XML output can easily be used to generate HTML for example for webgui's, using XSL templates. With the verbosity of the current XML, this is very easy.

hummm you should separate the XML schema from the data, so you don't need to specify the type again and again for the same entities ... it will save a lot of place, and will keep the usability of XML code.

Fabrice wrote:

hummm you should separate the XML schema from the data, so you don't need to specify the type again and again for the same entities ... it will save a lot of place, and will keep the usability of XML code.

But that would be a true pain when you want to use XSL on the XML. XML Schema's are only useful when you want to validate the XML data with teh DOM, otherwise it's a true pain, not to mention the horrible schema syntaxis as well.

Fishy wrote:

My biggest dilemma has been in segmenting my BL properly. Specifically in the area of not duplicating BL code when you have tables that overlap into other tables that perform different types of Business Logic. Any suggestions on that would be helpful.

Where we have tables that overlap we add logic to a relvent business process component - if the logic does not tie to a specific entity we may use a dataTable to work with the data....

Wayne - what have you done to your "image"!!!