I know these topics have been covered in other posts, and I've read through most of the posts, however I'm hoping to get an up-to-date assessment of where we are with respect to using LLBLgen Pro in conjunction with other frameworks.

I hear good things about Aspect Oriented Programming and would like to move in that direction.

• To what degree is LLBLgen an AOP solution?
• How much overlap is there between say, Spring.net and LLBLgen?
• Where does CSLA fit in?
• What other frameworks (including homegrown) are people using with LLBLgen, and why?
• Have people evaluated frameworks and decided to go with LLBLgen alone? If so, why?
• What are the implications of .Net 3.5, LINQ, etc. on all of this? Is it premature to worry about that?

Any feedback on these topics would be helpful (I assume to others here, not just me).

AOP is a concept or methology. the technology used is irrlevant.

Spring.Net is a IoC/DI framework. there is no direct correlation with LLBL. You could use Spring.Net to implement LLBL objects within your application, but it's not necessary.

The little I know about CSLA is it's a 3rd party framework to automate the development of business logic. There is a LLBL implementation of CSLA. I looked over this briefly awhile back, and didn't see a need for CSLA with LLBL. My understanding is LLBL v2.0 and 2.5 have the features of CSLA. At least most of them in their own implementation.

v2.5 supports .Net 3.0. check Solution Design's road map for an ETA on Linq and 3.5.

Projects similar to LLBL are Ent Lib DAAB and nHibernate. neither of which come close to the feature set of LLBL. (personal opinion)

LLBL is a data access tool. Just like all other 3rd party tools, it's a piece of the puzzle to develop solutions.

For me I use Ent Lib 2.0. Exception, Logging & Caching to handle mundain system maintaince. However these objects are idependent of LLBL. for example. I use exception handeling like this

//alter MyCollection
try
{
    UnitOfWork2 uow = new UnitOfWork2();
    uow.AddCollectionForSave(MyCollection);
    uow.Commit(adapter, true);
}
Catch (Exception e)
{
   adapter.Rollback();
   ExceptionPolicy.HandelException(e, "MyPolicy");
}

where MyPolicy will log the exception according to the Ent Lib configs. In a similiar maner I use the Caching block to store static lookup values in memory.

Top 3 reasons why I use LLBL: 1. Support : 2nd to none 2. Predicate System : how cool is this MyEntityFields.MyField <= 100; 3. Flexibility : I haven't found TSQL statement I can't create with LLBL. and the generated code is very extensible.

I haven't upgraded to 2.5 yet. I will probally use this on my next series of projects.

jmeckley wrote:

AOP is a concept or methology. the technology used is irrlevant.

Hmm... lots to think about in your response. Thanks!

One thing I noticed is that LLBLGen 2.5 supports DI (Depdency Injection). This exotic-sounding technique sent me on a circuitous path that led me to Fowler's book on Enterprise Patterns (many of which are in Spring.Net), and well as Jimmy Nilsson's book on applying these patterns in C#/.Net.

DI as I understand it (and I only hazily understand it so far) is part of the AOP approach. Is it fair to say that LLBLgen is moving in the direction of tha AOP approach to development?

Like you I am wondering if there is any real need for a major framework on top of LLBLgen.

As an aside, have you seen this: http://www.postsharp.org/

I haven't seen post sharp. the DI framework included with LLBL is specific to LLBL. it is not meant to mirror Spring.Net or the like.

I'll address briefly the questions put forward. A lot of things are already discussed in this thread.

csmac3144 wrote:

I know these topics have been covered in other posts, and I've read through most of the posts, however I'm hoping to get an up-to-date assessment of where we are with respect to using LLBLgen Pro in conjunction with other frameworks.

I hear good things about Aspect Oriented Programming and would like to move in that direction.

• To what degree is LLBLgen an AOP solution?

As with all these kind of techniques, you could debate for years about a definition, so I won't do that. AOP is about weaving aspects into runtime code at defined spots, so you can extend existing code without modifying it, keeping things separated. LLBLGen Pro doesn't use weaving, though has a mechanism which offers this for authorization, auditing, validation and concurrency predicates: through the objects which are plugged into entities and which are called from inside the framework. So in a sense the weaving has already been done, you just have to write the aspect. It's not really AOP, so I won't call it that, but in essence it uses similar things, only not weaving: where the framework calls what is pre-determined.

• How much overlap is there between say, Spring.net and LLBLgen?

Spring.net is a total different framework. So you can use both together to extend eacthother. ActiveRecord isn't part of spring, is it?

• Where does CSLA fit in?

Not that I know of, CSLA is a different framework altogether which dictates how business objects should be written and behave. I don't know the inner workings of CSLA so I don't know how much they have in common.

• What are the implications of .Net 3.5, LINQ, etc. on all of this? Is it premature to worry about that?

Linq is a language construct and allows the specification of select statements. It's just a part of the whole set of things you can do with data in a database, so you will have to use the O/R mapper code as well.

I'm currently busy with writing Linq to LLBLGen Pro. It's not stuff I enjoy: there's little documentation and it simply comes down to boring code which actually adds little to nothing to the LLBLGen Pro framework other than a different way to specify some types of queries. People assume they can formulate all select statements in linq but that's not true, you can't formulate prefetch paths for example, so I have to find a way to specify these as well... You can follow my progress on my weblog.

csmac3144 wrote:

One thing I noticed is that LLBLGen 2.5 supports DI (Depdency Injection). This exotic-sounding technique sent me on a circuitous path that led me to Fowler's book on Enterprise Patterns (many of which are in Spring.Net), and well as Jimmy Nilsson's book on applying these patterns in C#/.Net.

DI as I understand it (and I only hazily understand it so far) is part of the AOP approach. Is it fair to say that LLBLgen is moving in the direction of tha AOP approach to development?

"dependency injection" is simply a much overloaded term, especially caused by mr. Fowler (no I'm not a fan of mr. Fowler). Check the wikipedia page about dependency injection and the discussion page of it .

Dependency injection is very simple: inject an instance of a class X into an instance of a class Y because Y depends on X at runtime, and you don't want to set the instance of X INSIDE the instance of Y. That's it.