http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I'm a fan of your features/concepts architecture and I really like their isolation but I'm thinking that how I can apply it on a real project that I'm working on. We have "create and edit documents" scenarios among the features of our application. These scenarios contains a complicated approach and a simpler approach according to user preferences (we have two forms -a full form against a summary form-for each scenario and we are using the same form to create and edit ) The questions is how we can isolate these features so that we don't have to change all forms if there's a new piece of data should be added to them. One thing that comes to my mind is to use a user control on our views but I'd like to have your opinion on this matter. Thanks again http://ayende.com/4333/effectus-isolated-features#comment13http://ayende.com/4333/effectus-isolated-features#comment13Mon, 04 Jan 2010 11:19:20 GMTA "review" of the Effectus example was published in the José Romaniello blog. [jfromaniello.blogspot.com/.../...ing-effectus.html](http://jfromaniello.blogspot.com/2009/12/reviewing-and-changing-effectus.html)http://ayende.com/4333/effectus-isolated-features#comment12http://ayende.com/4333/effectus-isolated-features#comment12Tue, 22 Dec 2009 12:29:57 GMTJason, Yes, you are making absolute sense http://ayende.com/4333/effectus-isolated-features#comment11http://ayende.com/4333/effectus-isolated-features#comment11Tue, 22 Dec 2009 07:15:07 GMTBrainboost, var presenter = new Presenter(); presenter.OnSave(); etc... They are basically POCO classes, so you don't really need to do much to test them http://ayende.com/4333/effectus-isolated-features#comment10http://ayende.com/4333/effectus-isolated-features#comment10Tue, 22 Dec 2009 07:14:20 GMTJosh, I don't like deep hierarchies, so I would probably go for the second version. OTOH, if I have a LOT of features, I would have Features\Contact\EditContact at some point, just to make sure that everything is arranged in a way that I can work with. http://ayende.com/4333/effectus-isolated-features#comment9http://ayende.com/4333/effectus-isolated-features#comment9Tue, 22 Dec 2009 07:13:15 GMTDavid, Nope, a concept in Effectus is showing screens with data bound to them. http://ayende.com/4333/effectus-isolated-features#comment8http://ayende.com/4333/effectus-isolated-features#comment8Tue, 22 Dec 2009 07:12:10 GMTNice code and explanation. I agree with brainboost that adding unit tests to the project will be very beneficial to us. ;=) http://ayende.com/4333/effectus-isolated-features#comment7http://ayende.com/4333/effectus-isolated-features#comment7Mon, 21 Dec 2009 22:01:12 GMT@Jason - you are making sense and I like the clock analogy. In "business logic" layer code reuse is a bad thing because it means logic reuse, which introduces hidden dependencies between functions that would be unrelated otherwise. If you have large applications you want to keep everything as local as possible, so you don't have to analyze the whole codebase to make changes to a single function. Ayende has chosen a wise, however somewhat bloated, approach to isolating features. I'd rather use script/DSL files to contain higher-level functions, each feature in its own file, but the method is not that important. Another aspect is the organization of the code - IMHO the static code structure defined by packages/classes/inheritance is good for infrastructure code, but not so good for business logic. For the logic its much better to group source according to business functionalities provided - for example by business processes supported by application. http://ayende.com/4333/effectus-isolated-features#comment6http://ayende.com/4333/effectus-isolated-features#comment6Mon, 21 Dec 2009 20:26:14 GMT"Trying to apply DRY and consolidate common pieces of code would introduce dependencies between features, and that is a bad idea." What I hear you saying is: 1. It is generally bad to have one feature depend on another. 2. It is also generally unhelpful for features to reuse a common codebase (e.g. the Model for the CreateNew feature and that of the Edit feature are identical instead of reusing a common BlahModel). I assume this would be because, even though they may happen to be identical at different times (as a broken clock is right twice per day), it is generally _not_ true that they _shall_ be the same--i.e., they are the same by accident, but will likely vary by design--and should therefore not share code in common. Is this correct? Am I making sense? http://ayende.com/4333/effectus-isolated-features#comment5http://ayende.com/4333/effectus-isolated-features#comment5Mon, 21 Dec 2009 18:07:32 GMTMaybe I missed something but i have no idea how to test presenters. Granularity of IPresenter's too low to mock it and most valuable properties like Model don't allow to apply IoC in easy manner. Am i wrong? http://ayende.com/4333/effectus-isolated-features#comment4http://ayende.com/4333/effectus-isolated-features#comment4Mon, 21 Dec 2009 15:40:35 GMTI know this is a minor detail about how you are doing things, but obviously in a larger application you would have more than one Edit screen.. would you do a deeper nesting of your directories to be more like: -Features -Contact -Edit -Company -Edit or go the route of -Features -EditContact -EditCompany http://ayende.com/4333/effectus-isolated-features#comment3http://ayende.com/4333/effectus-isolated-features#comment3Mon, 21 Dec 2009 15:24:58 GMTComponent naming makes sense, altough it makes Resharper navigation a bit slower. http://ayende.com/4333/effectus-isolated-features#comment2http://ayende.com/4333/effectus-isolated-features#comment2Mon, 21 Dec 2009 12:22:40 GMTSo in light of the Concepts & Features article... Does the namespace Effectus.Model contain the Concepts? http://ayende.com/4333/effectus-isolated-features#comment1http://ayende.com/4333/effectus-isolated-features#comment1Mon, 21 Dec 2009 12:18:51 GMT