I have been doing a lot of studying lately. I read a couple of great books (C# in depth) and (LINQ in Action). I found that when you want to learn a new technology that includes a change in paradigm then its best to learn its building blocks.

A blog entry (http://blogs.msdn.com/wesdyer/archive/2007/03/09/extending-the-world.aspx) by "Wes Dyer" talks about extending the world

Typically for a given problem, a programmer is accustomed to building up a solution until it finally meets the requirements. Now, it is possible to extend the world to meet the solution instead of solely just building up until we get to it. That library doesn’t provide what you need, just extend the library to meet your needs.

Now I know that everyone on this Forum had to deal with LLBL's entities one way or the other (some people opted to bypass them and build their own DataTransferObjects). LLBL offers the selfService model which is very convenient but only designed for Client/Server 2-tier architectures. The Adapter model though solved this issue by breaking the DataAccess (creating the Adapter) code away from the Entity classes did so too well because to extend the entity classes in any way we had to opt for inserting the code in partial classes at the DAL tier instead of actually extending the code where it is needed; in the upper BL tier (which is not bad as this assures proper tier segregation as we have all been preaching all this time)

I hope you see where I am going with this. Is it feasible to think that the BL can extend the entity classes with static methods similar to what everybody is doing in the Manager classes created in the BL.

This is how LLBL's own LINQ provider (and every other LINQ provider) is written; using extension methods that extend a type.

So, I could extend the CustomerEntity class (in the BL) with a method like SaveCustomer(). Such method would appear as an instance method for any customerEntity variable and the UI (or othe BL classes) would deal with this the same way LLBL's SelService classes have been doing..

Is this viable or doable or am I missing a big pitfall that would invalidate this way of thinking???

Usually I use Service Objects to persist/retrieve entities and collections. Extension methods are nice but what really do you gain? So I created a generic BaseService abstract class that does a lot of the generic work (like save entityCollection or save entity or get entitycollection etc.) and then I derive concrete Service classes that add anything extra.

In an effort to make the service layer provider agnostic I use IoC (dependency injection) to inject a concrete IAdapter object that has a method to create IDataAccessAdapter objects.

I hope this makes sense.

Omar,

I was thinking the same thing last night.

I posted this: http://llblgen.com/TinyForum/Messages.aspx?ThreadID=14296

Which I think is the same question you are asking.

Have you done anything more with this since you posted?

Gabe

Hi Gabe,

I've gone through your thread and seems we are on the same track. My personal thinking is to model this after the selfService model of LLBL. The line is drawn around SRP (Single Responsibility Principle) while taking into consideration the separation of behavior from Data.

This means I would add what is being termed as "Domain Specific" extension methods that would only make sense for the entity being extended. Example, extend a book entity with a method to get bookWithPagesMoreThan().

I would not claim this is the right way to do it but what I am shooting for is a change in paradigm to a more functional way of designing my BL classes.

I am starting a new project that I hope to get a chance to experiment this approach in designing the BL classes..

Omar,

Hello, thanks for the reply.

I am not certain that I understand your example.

Do you mean that you are extending methods to your entities to do things that affect more than just one entity?

Could you give me a little more code of how your extensions would be used?

My feeling after thinking about this a bit more is that extensions are just an alternate way to access my manager classes. so i can do things like user.Save and User.FillRoles which would fills the role collection of a user entity.

When i type User dot I want to see all the things that an instance of a user entity can do.

When I type UserManager dot I want to see everything that can be performed on users like returning new entities, or modifying several entities at once, and also simple things that can happen on a single instance.

I don't think I like this syntax of creating an empty container, then using extension methods of that to populate it. If i remember correctly i think this is how the self service worked.

Dim user as New UserEntity() User.FetchByPrimaryKey(66) 'this would fetch and populate the current user.

'starbucks is an existing CompanyEntity instance Dim users as EntityCollection(of UserEntities) users.FetchByCompany(starbucks)

'here is one that may be a little more confusing using this syntax

dim user as new UserEntity() user.Login(_userNameTextBox.Text, _passwordTextBox.Text)

' I think this is a bit clearer dim user as UserEntity user = UserManager.Login(_userNameTextBox.Text, _passwordTextBox.Text)

The reason I think this is because you can see that the Manager class is doing some work and populating the user with the results. There is no instance of the user until the login actually happens.

I am still working on getting my manager classes the way I would like them, but let me know if you are interested and I will send you one of my autogenerated classes.

Gabe

I posted more on the other thread I started:

Including one of my manager classes, and a sample of how extensions are used.

http://llblgen.com/TinyForum/Messages.aspx?ThreadID=14296