I think the place this is asked the most, in my opinion, is corporate america size companies. Places where architects are deciding the solutions, CTO’s are in charge of having a methodology passed down, etc… Not that this is bad, but I tend to feel a large amount of them have more control in a RUP or waterfall approach. I doubt many have coded TDD, test-first, stand up meetings with developers and customers, seeing agile unfold and work. Selling it to the developers in my opinion is not the hard sell. Sure, TDD is new to them, they don’t understand it, but I sense once they use it and are expected to use it, the outlook changes.

But outside of the developer perspective, ‘agile’ is probably seen as giving up control, something more corporate america architects and CTO’s aren’t going to adopt very quickly.

We need more project managers/upper management to understand and adopt agile methodologies. Most of the problem to me is lack of understanding or pre-concieved ideas, or better yet… I’ve always done it that way, don’t rock the boat 🙂

I think the place this is asked the most, in my opinion, is corporate america size companies. Places where architects are deciding the solutions, CTO’s are in charge of having a methodology passed down, etc… Not that this is bad, but I tend to feel a large amount of them have more control in a RUP or waterfall approach. I doubt many have coded TDD, test-first, stand up meetings with developers and customers, seeing agile unfold and work. Selling it to the developers in my opinion is not the hard sell. Sure, TDD is new to them, they don’t understand it, but I sense once they use it and are expected to use it, the outlook changes.

But outside of the developer perspective, ‘agile’ is probably seen as giving up control, something more corporate america architects and CTO’s aren’t going to adopt very quickly.

We need more project managers/upper management to understand and adopt agile methodologies. Most of the problem to me is lack of understanding or pre-concieved ideas, or better yet… I’ve always done it that way, don’t rock the boat 🙂

Simone Busoli has completed his series on dependency injection (link to last part, but each part includes links and summary of the other previous parts) with Castle Windsor’s Inversion of Control open source project. This is a fantastic set of blog posts!!!

I’m probably biased toward Castle because I’m hooked on all their offerings as it’s been posted here more than once 🙂

But I find that Windsor is very well done. It offers both constructor and setter injection models. It can be used at runtime or through the configuration files. I use this container in several of my development projects. ie. I use Windsor with my asp.net solution to handle the management of my DAO layer (DaoFactory : IDao).

This last article covers aspects I was unaware of, including how the ‘lifestyles’ work, as well as a fantastic start on how to extend Windsor with ‘facilities'(I’ve been looking for a good factory pattern setup with Windsor!). Simone create a FactorySupport facility, that is based on the factory method design pattern and walks through the steps:

“By registering the FactorySupport facility you have indirectly extended the container with a full new API which lets you use a new syntax to configure components and benefit from the facility “

It’s good to see these contribution blogs. I’d like to see the Microsoft Patterns and practices team embrace and use Windsor, I think it’s a step up from their ObjectBuilder…. but that is another post (or rather rant?) … I’ll let you go read the article 🙂

Edit:

I had asked Simon how Windsor can handle a factory method that determines the type of object to create at runtime. He was gracious enough to give me a link to an article called ‘Referencing Implementations by Key’ (from BitterCoder)

I must agree with Ayende, and after many many projects & years of developing webform applications, what he writes is true. Webform’s appeal is in it’s separation of the UI from the code with a page controller architecture. It’s very similiar to what you expect in a Winform’s application. However, the page lifecycle and the attempt to give the illusion of state becomes a burden on a more complex page. Some areas of webform development is nice – mostly databinding and some of the new ajax capabilities. But even then you will find your fight the page lifecycle rather than just develop a solution.

So, in comes Monorail. Monorail removes this page lifecycle from asp.net and provides a viewengine instead. NVelocity or Brail, etc…

The one thing I would personally like to do is to eventually learn boo and brail. Ayende has written some Monorail smart components that show how easily it is to implement your own controls. I would love to see the Monorail community create a repository of view components with common functionality (ie. validation components, grids, ajax components, etc.).

Monorail doesn’t attempt to hide how the web works. It makes integrating in components quite simply. ie. I used the Yahoo Development tab control make in javascript. Rather than fighting the page lifecycle, registering my javascript with the page, etc… I simply included the tab view in the html of my Monorail page and it works. Nothing is hidden.

I could go on and on, but I feel the response by Ayende is right on.

The only struggle I see right now is convincing your organization to adopt Monorail, but I would think the developers would quickly adopt it because it makes their life easier, and developers don’t have to constantly fight the page lifecycle of Webforms.

For me the added benefit of Monorail also includes the ability to plug in a DI/IOC container and utilize ORM capabilities. All are pluggable and can exist independently.

This was my response to his post:

On the MVC the biggest problem I have with WebForms is that the page logic is called prior to the â€˜controllerâ€™ logic.

â€œYou have reviewed the Page Controller pattern, but your page controller classes have complicated logic, are part of a deep inheritance hierarchy, or your application determines the navigation between pages dynamically based on configurable rules.â€

Sounds familiar of webforms â€¦

So, what does something like Monorail achieve?

â€œFront Controller solves the decentralization problem present in Page Controller by channeling all requests through a single controller.â€

I think the idea of â€˜postbacksâ€™ is what really complicates the webform model. You are managing different states by determing if you are in â€˜postbackâ€™ or not. That is the start of the complexity for me. Your left trying to manage the â€™stateâ€™ of that page through the statebag, session, etcâ€¦ to attempt to recreate that page.

I have used a MVP (presenter) setup, and although it does what you suggest, separating the presenter logic from the view logic, I still find working with a system like Monorail is much more straight forward.

But again,I see the differences as â€˜front controllerâ€™ vs. â€˜page controllerâ€™. Obviously both have tradeoffs

Declare a sort string or a SortProperty array. Note: This could be created and maintained by a custom editgrid.

Declare an instance of the DynamicComparer class using the generic constructor.

Call the sort method on the List<Person>.

Thatâ€™s it!

So whatâ€™s going on behind the scenes? Letâ€™s begin at line 2 of the previous example. At the time of instantiation of the DynamicComparer, the class will first parse the input string into a SortProperty array. These SortProperties will then be validated against the type we specified when instantiating the DynamicComparer, in this case, â€œPersonâ€. This validation checks if the Person class is public, if it has any public properties named â€œFirstNameâ€ and â€œLastNameâ€, if these properties are readable, and finally, if these properties are of a type that implements the IComparable interface. If any of these validations fail, the class will throw an exception. If the validation succeeds, the class will then generate a dynamic method using the specified SortPropertyies and instantiate an internal delegate pointing to the method. The â€œCompareâ€ method on the DynamicComparer will then in turn be able to invoke this delegate when called. This means that the comparer is ready for use.

Note: If you want to change the sorting of an instance of the DynamicComparer, you can call the â€œInitializeâ€ method on the instance and pass in a new ORDERBY string or a SortProperty array.

At the next step, we call the â€œSortâ€ method on the â€œpersonsâ€ list passing in a reference to the comparer.Compare method.

Very slick! Again, his source code is in the article, I suggest checking out the performance gains.

It’s about time…. just kidding.Â Repository pattern (see Martin Fowler description) is a good Domain Driven design practice for data access for persisting and retrieving domain objects from a data store.