Hi,

As a current customer of LLBL Gen Pro, and I must add we like the product and with custom templates to generate GUI (beta version) we are excited about the new possibility. At the same time, I would like to see what is the LLBL Gen Pro future direction. As we are training ourselves and investing time and efforts on it. What is my feedback on it (or question) is -

A) How LLBL Gen Pro can work with Enterprise Library? B) How LLBL Gen Pro can work with Web Service Factory? C) How LLBL Gen Pro can work with Web Client Software Factory? D) LINQ /DLINQ?

what is my secret expectation is to establish (build) Domain Model/Data access/Business layer Framework on LLBL Gen Pro and use other component around it to have our Enterprise Application Framework.

If any pointer on those side will be highly appreciated.

regards

Khuzema (Khojema Bohara)

Hello,

about LINQ you can see this post about the future : http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=8495&StartAtMessage=0&#46992

For the A B C, I don't use these from now, I saw a topic about Web Client Software Factory on this forum(i will post the url as soon as I find it again) .

Khuzema wrote:

Hi,

As a current customer of LLBL Gen Pro, and I must add we like the product and with custom templates to generate GUI (beta version) we are excited about the new possibility. At the same time, I would like to see what is the LLBL Gen Pro future direction. As we are training ourselves and investing time and efforts on it. What is my feedback on it (or question) is -

A) How LLBL Gen Pro can work with Enterprise Library?

In what way do you want it to work with EntLib that can't be done today?

B) How LLBL Gen Pro can work with Web Service Factory?

Could you give me an URL with more information about web service factory?

C) How LLBL Gen Pro can work with Web Client Software Factory?

Same as B. The terms are unfamiliar to us. Is it a pattern published by MS somewhere?

D) LINQ /DLINQ?

We'll add LINQ support before H1 2007, or if Microsoft changes a lot in Linq, later on. The thing is that at the moment there's very little information available how to properly implement Linq support. For example, you can implement Linq support for LLBLGen Pro using extension methods (easier) however Microsoft pushed the IQueryable interface, however this is much more complex and at the moment it's very quiet around IQueryable, so I (and other O/R mapper vendors I've spoken with last week agree with this) don't know what will happen with the internals of Linq at the moment. So it's a bit too early to already implement Linq support now, however we will implement Linq support BEFORE Microsoft ships Orcas.

DLinq and Entity framework: we will ship templates to fully support these frameworks out of the box. Also, during the year we'll receive new information about what Microsoft is planning for Entity framework (we dont expect DLinq will be released) and if we have to adjust our designer.

what is my secret expectation is to establish (build) Domain Model/Data access/Business layer Framework on LLBL Gen Pro and use other component around it to have our Enterprise Application Framework.

My question then to you is: would you like us to add more support for Aggregates/Repositories as explained by Evans to do more pure DDD ?

Hi,

Please find following Url -

A. Enterprise Library : http://www.codeplex.com/entlib B. Web Service : http://www.codeplex.com/servicefactory C. Web Client Software Factory: http://www.codeplex.com/websf

What I want may be is sort of whitepaper describing how LLBL Gen gel with other components (web client/web service/ent lib) or best practices.

May be its asking too much but thats just LLBL Gen user feedback/suggestions.

as Evan explained ???

regards

Khuzema WISDOM Corp

Khuzema wrote:

Hi,

Please find following Url -

A. Enterprise Library : http://www.codeplex.com/entlib B. Web Service : http://www.codeplex.com/servicefactory C. Web Client Software Factory: http://www.codeplex.com/websf

What I want may be is sort of whitepaper describing how LLBL Gen gel with other components (web client/web service/ent lib) or best practices.

Could you please answer my questions regarding A and D?

Regarding webservices: we have the philosophy that webservices should be about messages and leightweight DTO's and not about sending large entity graphs across the wire. So in other words, LLBLGen Pro sits below the webservice surface, it's used inside the service, not across services. You could use it of course across client-and-service, llblgen pro supports webservices and the xml serialization/deserialization logic, however in general best practises for webservices suggest you shouldn't look into object graphs sending across the wire, but more into messages where the service is a fixed featured service, and placed high in the application stack instead of a service which is placed low in the application stack. This isn't something we cooked up, it's something that's becoming more and more mainstream among SOA specialists (so I'm just venting what they're saying )0

as Evan explained ???

Eric Evans, one of the fathers of Domain Driven Design.

Since DDD is being talked about so much today, it might be nice to have a sample application demonstrating how LLB fits in with this architecture. Here is how I would envision:

• Code base uses the adapter model

• Create a repository for each aggregate root (would be nice to have an overload of the SaveEntity that specifies how far down to go in the graph so we can explicitly define our boundaries. Note, the repository would neatly package up the DataAccessAdapter.

• Thin Service Layer that demonstrates transactions across aggregate root boundaries.

Seems like most confusion on the boards is how thin to keep the service layer (or even use one).

Those are just a few things I can think of off the top of my head (read the book about 6 months ago).

Otis wrote:

Aggregates/Repositories as explained by Evans to do more pure DDD ?

YES YES YES :-)

How could the designer for example be of help creating repositories etc. ? It is of course possible to generate repositories / aggregates with pre-fab methods produced by a template and the meta-data available in the llblgen pro project, but wouldn't that be unworkable? I mean: IMHO it's best if the developer writes the repositories him/herself so only the code that's necessary is in the repositories.

Otis wrote:

How could the designer for example be of help creating repositories etc. ? It is of course possible to generate repositories / aggregates with pre-fab methods produced by a template and the meta-data available in the llblgen pro project, but wouldn't that be unworkable? I mean: IMHO it's best if the developer writes the repositories him/herself so only the code that's necessary is in the repositories.

Sorry, I didn't mean for the designer to generate the actual repositories, but leave that up to the developer. How would you recommend for example, with an OrderRepository, whos aggregate root makes up Order-OrderDetails-Product, save for example only these three entities. With recursive saves now, they entire graph is saved, but when dealing with aggregate roots, we only want to save what is defined within that root. Would we need to pull out the entities manually and save each one seperately?

KristianP wrote:

Otis wrote:

How could the designer for example be of help creating repositories etc. ? It is of course possible to generate repositories / aggregates with pre-fab methods produced by a template and the meta-data available in the llblgen pro project, but wouldn't that be unworkable? I mean: IMHO it's best if the developer writes the repositories him/herself so only the code that's necessary is in the repositories.

Sorry, I didn't mean for the designer to generate the actual repositories, but leave that up to the developer. How would you recommend for example, with an OrderRepository, whos aggregate root makes up Order-OrderDetails-Product, save for example only these three entities. With recursive saves now, they entire graph is saved, but when dealing with aggregate roots, we only want to save what is defined within that root. Would we need to pull out the entities manually and save each one seperately?

That's indeed a problem at the moment if you want to go that route. So if you want to have these kind of repositories, you need support from the designer, templates, runtime libs etc.

You of course don't want to do things manually if things can be automated, though I personally think it's a bit of a problem with the whole idea of repositories and aggregates. though it's not that hard to solve IF you realize that an entity can only be used once in all your repositories. So if you have an aggregate with order-orderdetails-product, it shouldn't be the case that product is referenced somewhere else as well, in another repository.

So in that case, it could be possible, in theory, to define aggregate roots in the designer (i.e.: you group order, order details and product), so the designer simply eliminates relations to entities outside that group. These relations then also don't end up in the code, and your repositories are working automatically OK.

Though it's a bold step for us to take, as we then make DDD a designer feature, and we then assume that people understand what DDD is and HOW to implement it (perhaps we should ship Evans' book with the app )

Sorry for late reply,

A) What is my thinking is otherthan DAAB/Caching Blocks etc in Enterprise Library, how we can use other Blocks like exception handling, logging etc., with LLBL Gen Pro. ( I am still working on it). The idea with this is NOT to re-invent a wheel already created somewhere else.

D) Aggregates/Repositories - it would be fine as mentioned by KristianP. My actual concern is compatability with Linq/Dlinq and Entity Framework as coming with next version of ADO.Net and LLBL Gen pro.

Note: I am not guru in DDD as such (still learning), we have working knowledge where in we can use tool like LLBL Gen Pro to assists as .

thanks

Khuzema

Khuzema wrote:

Sorry for late reply, A) What is my thinking is otherthan DAAB/Caching Blocks etc in Enterprise Library, how we can use other Blocks like exception handling, logging etc., with LLBL Gen Pro. ( I am still working on it). The idea with this is NOT to re-invent a wheel already created somewhere else.

They shouldbe usable right now, as these blocks are often used in code which also consumes other objects, like entity classes.

D) Aggregates/Repositories - it would be fine as mentioned by KristianP. My actual concern is compatability with Linq/Dlinq and Entity Framework as coming with next version of ADO.Net and LLBL Gen pro.

Oh, don't worry about linq, we'll have a Linq compatible layer out this summer. The LLBLGen Pro designer will be able to produce Linq for sql/entity framework classes + support code by the time MS releases Orcas.

Thank you for your reply, satisfies me. Just one obscure request, I have seen in one of other O/R mapper (while evaluating, b4 purchasing LLBL Gen pro) that they have facility to test the entity like "Select CustomerEntity where CustomerEntity.CustomerID ='BLOPS'" then the tool will show the query generated by the O/R mapper and the result.

I think this will help us in many ways Or can we do it now somehow.

regards

Khuzema

I understand what you mean, though would that really be helpful? I mean: if you don't know what the filter code you just wrote will do, you thus are guessing. If you do know the sql that you want, the best tool you need is a sql -> C# code converter, not C# -> SQL as that will lead to trial/error sequences till you see the sql you needed.

Unfortunately, sql -> C# is very hard, as the sql can be very obscure and therefore unable to convert to C#/llblgen pro constructs.

We have debugger visualizers which at debug time, allow you to see what the several parts of a query will result in (SQL).

thanks, I will work with debugger visualizer.

Khuzema