.NETTiers DRY Problem, Better use of generics?

Hi guys,

I just got back from building a project on Monorail using ActiveRecord, and I've noticed quite a difference in their approach vs ours.  ActiveRecord is built on the NHibernate stack, and there is little duplicate code in NHiberate vs NetTiers.  Granted, NHibernate isn't auto-generated, but I think we could reduce our DRY problem greatly without sacrificing the features that make NetTiers so useful.

For example, for each Service class that is generated, NetTiers creates a partial class file with a generated base class file.  All of this code is redundant and duplicated.  If one wanted to modify say, the way in which SecurityContext is implemented, they'd have to do it in every class.  The same is true across the entire system.  Providers, Helpers, Entities, Validation, etc.

I'm wondering what are the thoughts in the community regarding this?

For example, if you have a CustomerService class, and open up the generated CustomerServiceBase partial class, nearly all of that code in there could be moved into a more comprehensive generic ServiceBase<T> class.  Then, you can eliminate the many of the partial classes, and the CustomerServiceBase class altogether.  CustomerService can inherit from ServiceBase<T>, and still contain all the custom logic that the developer doesn't want regenerated.   As far as I've seen, this refactoring applies throughout most of the system.  Instead of having hard-coded provider classes (such as dataProvider.CustomerProvider.GetPaged() etc, the ServiceBase<T> can just call ProviderRepository<T>, passing in customer.  Another area where this would reduce the code is in the CustomerFilterBuilder classes, etc.  These are simply inheriting from SqlFilterBuilder<TColumn> anyway, so it is ripe for refactoring.  I would estimate that one could reduce the codesize of the framework by >60% or even more.  This would allow for easier refactoring of upcoming feature requests, such as the integration of popular DI frameworks, or the new Validation/Policy Injection frameworks from MS.  As it stands now, refactoring is a bit of a daunting task.

Thoughts anyone? 

 I am a CSLA.Net user who was prompted to look at .Net Tiers thru David Hayden's blog.

I like the architecture a lot but I agree with you that a lot of code can be refactored.

Especially when you look at CSLA.Net source code, you can see how a lot of common code has been encapsulated in base generic classes.

I hope other people will contribute to this discussion to  make .NetTiers more leaner that it currently is.

This could be made to .Net 2.0 version of netTiers.

Now that .net 3.5 is out, i think nettiers should focus on this version,  using all LINQ and other stuf. VS2008 job on generating classes and data acces providers is pretty well done, but sure .nettier community can top that. 

Even using .NET 1.1 you could reduce the codebase quite a bit.  Look at NHibernate which doesn't even have generics yet (as far as I know) and yet it's quite DRY. 

Speaking of LINQ, I've taken a look at PLINQO lately, and I thought to myself "Where is NetTiers going with this?".

Excuse me while I study up on some more LINQ.

After working on the SortBuilder, I started noticing the DRY problem as well. 
Generics have always been something that have been at the back of my mind, something almost 'mystical' that other developers use for what purposes... i didn't understand. 

So I took it upon myself to start educating myself more on what generics are and how they are used.  I think I've reached an opiphany in the last few days!

Anyway, I'm slowly starting to read my way through Microsoft's Intro to Generics.  It is definitely a good read.
http://msdn2.microsoft.com/en-us/library/ms379564(VS.80).aspx

I will definitely take a look at what I could do to help solve the NetTiers DRY problem.  I certainly hope that this thread continues to be active.

Hi,

What is this DRY that you are talking about?

Thanks
Brendan

DRY refers to Don't Repeat Yourself.  If there is a DRY problem, it means that we are repeating code unnecessisarily in the code.

What we are trying to do is refactor the NetTiers templates in such a way as to not repeat the same code over and over again in the generated code.  This would have an effect reducing complexity and the size of the code base, as we don't have to change code in multiple places, just once.

For example, take a look at the Service Layer that is generated.  For each entity that is generated, you end up with a [EntityName]ServiceBase.generated.cs file.  This generated class contains data access methods such as GetAll, GetPaged, Find, etc.  If you start to look at the differences between each entity service base class, you'll start to notice that there isn't a lot of difference in the code, just the types that are returned, or the specific data provider that is called.

We could, theoretically, move all of the similar methods in to the ServiceBaseCore.generated.cs file, which all of these entity service base classes derive from.  By making use of generics, we can still return the proper types from these methods, but it eliminates the need to repeat the code in the actual entity's service base classes.