Hi Guys,

I'm looking at writing a framework for my company's future ASP.Net development. Mainly for code reuse, scalability, internationalisation etc. etc. I'm trying to get an idea of how to go about it. I want it to contain all the latest features so might consider going for WCF, WF, SilverLight etc. (as we see these would be required in our future apps). I'm also looking at starting with some base Framework like spring.Net, may be using NHibernate, Application Blocks, Third party controls ...

So using my framework someone should be able to extend DTOs, Web Services, Remoting, MSMQ messages, some UI controls, DB Persistance, Exception Handling, logging messages, Caching, validations etc. etc.

This may be vague at this stage as I can see only the big picture.   Based on what I have explained, any input from you exprerts will certainly set the launching platform for me. Any do's, don't, pitfalls will help me as well. Any other frameworks, tools you can think of will be also an added bonus.

Thanks in advance.

Cheers,

Steve

Take a look at the Castle Project stuff - http://www.castleproject.org/ 

Here are some tutorials to get your started: http://wiki.bittercoder.com/(X(1)S(ijonjt55unuot255brk3rw45))/Default.aspx?Page=ContainerTutorials&AspxAutoDetectCookieSupport=1

Windsor supports services and facilities so you can extend it pretty much any way you can think of - and Windsor is (in my opinion) way better than Spring.

I've used Windsor as a base for developing a Web Application Development Framework for 2 different companies over the last few years and it's been great.

You could also consider looking at the Web Client Software Factory http://msdn2.microsoft.com/en-us/library/bb264518.aspx - I've taken a look at this and it seems alright if you're keen on going down the Enterprise Library path with things like logging, exception handling, caching, validation, data access etc. I've found in the past that Enterprise Library has been a bit too heavy weight (and slooow for logging) and has too much of a learning curve for the rest of the team.

Third Party Controls - in my experience ComponentArt controls have been a nightmare to work with. They look nice and flashy but under the covers they're a mess. This might be different now but that's how it was around 2 yrs ago.

Thanks for the recommendation. I'll definitely take a look at Castle Project.

I'm hoping for more people to contribute with other suggestions. Probably with a bit more detail on how to approach the whole design. I've already built large apps on top of existing frameworks and not written one from scratch. So trying to be a bit more careful before I mess it up :)

Another thing - I definately recommend code generation for your DAO and Entities. I use CodeSmith and it's good - although I've heard of others (MyGeneration, NextGeneration etc). You should be able to integrate your code gen stuff into VS so your dev team can easily generate the code required after a schema change. One place I've worked at did this with a VS addin.

Thanks again. I've used codesmith as well. It is a great tool to have. 

 You should take a look on Visual WebGui (http://www.visualwebgui.com/), they have an open source framework that does it all of the above.

I hope this helps,

Jiggi 

stevios:

Hi Guys,

I'm looking at writing a framework for my company's future ASP.Net development. Mainly for code reuse, scalability, internationalisation etc. etc. I'm trying to get an idea of how to go about it. I want it to contain all the latest features so might consider going for WCF, WF, SilverLight etc. (as we see these would be required in our future apps). I'm also looking at starting with some base Framework like spring.Net, may be using NHibernate, Application Blocks, Third party controls ...

So using my framework someone should be able to extend DTOs, Web Services, Remoting, MSMQ messages, some UI controls, DB Persistance, Exception Handling, logging messages, Caching, validations etc. etc.

This may be vague at this stage as I can see only the big picture.   Based on what I have explained, any input from you exprerts will certainly set the launching platform for me. Any do's, don't, pitfalls will help me as well. Any other frameworks, tools you can think of will be also an added bonus.

Thanks in advance.

Cheers,

Steve

Hi Steve,

In my opinion follow an Abstract class approach from design point of view, although you can go about with interfaces, however I am sure you know the downside of finding out something too late and the rippling effects. However you can leave some critical bits in terms of interfaces so that it allows the code to consume interfaces, where people can plug in their own implementations and code keep on working without underlying details. This will allow for code extension and re-use and preserve the integrity of code.

Since you are planning it from the start, you may wish to consider Db40 rather then NHibernate etc as these preserve objects directly rather then the complicated mesh and are scalable and more faster. For controls etc, provide them with overridable method so people can extend the base control etc and perhaps an interface for validation would be more logical. There is a lot of inbuilt stuff in the .net framework for caching however very little for proxy caching so thats one area you may like to consider. The new Enterprise library should be very useful in dealing with framework 3.0.

Not to be too flippant - but my word of advice is...don't. You have no idea what you're writing a framework for - which is pretty much an automatic recipe for failure. Build apps, extract frameworks.

I disagree with naturehermit on the idea to use abstract classes and interface only 'some critical bits'. If you want to be able to test this framework (which given that you want this framework to scale I'm assuming you want it to be reliable as well, so testability is implied) you should interface as much as possible. It will give you a great pluggable architecture (especially used in conjunction with Windsor) and will make unit testing alot easier by being able to easily mock your objects with a mock framework such as Rhino Mocks, EasyMock.Net, NMock etc (I recommend Rhino Mocks). I think abstract classes should definately used to create your base classes but I also believe they should be interfaced. I guess it's just my personal preference, but it's worked really well for me in the past.

Not necessarily.... I'm planning a sort of parallel approach... start with framework on common functionalities like dbaccess, security, error handling, logging etc. (these will be required in almost any apps. right?). Then move on to building apps as they come and when I see an opportunity for extraction, make them part of the framework which I need to plan on making it very extendable to take care of future needs. Thanks for words of caution though :)

Sorry previous reply was meant for comments from brackett@ufl.edu

Mercury082:

I disagree with naturehermit on the idea to use abstract classes and interface only 'some critical bits'. If you want to be able to test this framework (which given that you want this framework to scale I'm assuming you want it to be reliable as well, so testability is implied) you should interface as much as possible. It will give you a great pluggable architecture (especially used in conjunction with Windsor) and will make unit testing alot easier by being able to easily mock your objects with a mock framework such as Rhino Mocks, EasyMock.Net, NMock etc (I recommend Rhino Mocks). I think abstract classes should definately used to create your base classes but I also believe they should be interfaced. I guess it's just my personal preference, but it's worked really well for me in the past.

On what grounds to you disagree? (merely usability to test doesnt warrant a certain design)

1. As you are aware that interface programming though good has its own pitfalls, as any change in code will ripple across the whole framework and any dependencies

2. Abstract class change wont ripple across..

Although I proposed both, because we are all suggesting an architecture to a possible framework and hence its all subjective..

I agree with you that both abstract classes and interfaces are definately useful however I disagree with you on the idea that only 'some critical bits' of a framework should be interfaced. Testing is an important part of the software development life cycle and is the only way to ensure bug free, reliable code. If it is difficult to write unit tests, developers either a) won't unit test or b) won't unit test thoroughly. The pitfall you mention, of changes to an interface rippling across the framework is valid however as long as care is taken with versioning and releases of the framework, it shouldn't be too big a problem (at least, it never has been for me). Of course testability on it's own doesn't warrant a certain design however I believe it should be one of many considerations when designing a framework architecture. Testability is not the only advantage of interface programming though. It also loosely couples components and provides a nice pluggable architecture (as you mentioned in your previous post). As you say - it's all subjective, and I guess again it comes down to my personal preference. I'm just adding my 2 cents based on my experience :)

Hello again,

Mercury I didnt say that testing should be avoided as it is an important part, what I said again..and I am going to repeat is...Usability of testing (certain testing methodology) should not influence our design decisions.

Good programmers always program to interfaces, however interfaces do have issues which is why the .net framework itself is built on abstract classes. A Framework is a huge undertaking and henceforth any change owing to interfaces is a change across the whole framework, which is not a good idea whether there is versioning or not.

You are right, that you are saying it based on your personal experience (and its a very valid choice...and , but then have you been involved in any framework development (well just to assure you...I had been but on a very little scale)?? Framework is a huge undertaking and require careful design considerations.

best regards

Hi naturehermit,

I see what you're saying about the .net framework and i believe that the lack (edit: sparseness) of interfaces in the .net framework is one of it's pitfalls. Just a personal preference obviously. Although I am aware of the arguments against usability of testing influencing design decisions, usability of testing does influence my design decisions to a degree, although not entirely.

I mentioned it in a previous post, but yes, I have had (commercial) experience with web application framework development. I've been working on web application frameworks for just over 2 years, so I guess my experience may not be as extensive as most other posters but I felt I might as well add what I've learned so far and what's worked for me.