Johnny Halife’s Blog

Last week I was discussing with Matías about the implementation of DFO (Design For Operations) for a system we are building at Southworks. Our discussion took us to an Ayende’s post that talks about Logging The AOP  Way for .NET. At that moment we thought that’s what we want.

Later on, reading ScottGu’s blog, we realized that a filtering pipeline has been built for the ASP.NET MVC, so we thought about mixing what ScottGu’s blog says to achieve what Oren’s was posting on Logging the AOP Way.

I have divided this post in two parts, the first is the conceptual part where I’m going to discuss a little bit about the Filtering model of ASP.NET MVC and then I’ll show a little how-to build a custom tracing filter.

What are ASP.NET MVC Filter Interceptors?

As described in ScottGu’s post Action Filter Attributes are declarative way to inject code that can be executed pre and post controller’s action execution. Also the same can be done for pre and post ActionResult conversion into an ASP.NET response. This enables another way to do AOP and achieve for example the logging described by Oren’s at his post.

How do they work?

In order to understand how do they work let’s analyze how does the ASP.NET MVC pipeline goes. Below is a diagram that demonstrates how does an action flows from the HttpRequest until the ActionResult gets executed.

Now, let’s go one by one the items diagrams and I’ll try to explain what’s happening on each part:

1. The user makes a call using the browser.
2. Given the URI of the request the ASP.NET MVC Handlers looks for the appropriated controller using the Routes configured on the Global.asax. Prior instantiating the controller a ControllerContext is created. It wraps ,among other things, the current HttpContext for a given request execution.
3. The ASP.NET MVC engine, instantiates the appropriated controller passing the current context as a parameter.
4. The controller executes the action that correspond to the current Route.
5. As a result of the Action execution an ActionResult is returned to the context, given the ActionResult implementation type (must inherit from ActionResult) it might be turned into a View (ASPX Page) or JSON as an example.

Now that the baseline execution context is a little bit dissected let’s explain where does the ActionFilter attributes hook to this model.

The items squared with black on the diagram above are the hooks that can be used to inject the code. Those are the interaction points where we can create our hooks and perform crosscutting operations like logging, tracing, error handling and even authZ and authN.

• OnActionExecuting. The ActionExecuting contains all the data about the action that is going to be executed prior its execution.
• OnActionExecuted. The ActionExecuted contains all the data gathered after the action execution.
• OnResultExecuting. The ResultExecuting contains all the data about the ActionResult that is going to be executed. Two of the differences that you will find between this and the previous hook are:
  • If the Action execution ends in an exception you  might not reach this point.
  • If the user called for example "View()" which renders the default view for that action, in the previous one you don’t know the view name.
• OnResultExecuted. The ResultExecuted contains all the data gathered while the ActionResult was turning into an ASP.NET Response.

Up to now we understand how does this ActionFilter pipeline works and which data we can get from it. Now, you might be wondering how do you get this in your code. It’s just simple as decorating your Controller and/or Action with the desired Action Filter attribute.

[TraceFilter]
public ActionResult Index()
{
    ViewData["Title"] = "Home Page";
    ViewData["Message"] = "Welcome to ASP.NET MVC!";

    return View();
}

In the example above I placed a custom attribute called TraceFilterAttribute that is a custom Filter I have created for demo purposes. Wondering how? Read below!

Do it yourself, your own ActionFilterAttribute in 5 minutes.

In this section we will discuss how to create a custom attribute. This attribute will trace the calls to the controller and log them like:

The log entry above displays the Date Time the entry happend, the warn level [Debug ||  Fatal || Error || Information] and the parameters if they were any.

Step by Step sample

1. Open Visual Studio (ASP.NET MVC works on Web Express versions of VS2008).

2. Create a new ASP.NET MVC Web Application and name it as you want.

3. Using the Solution Explorer, create a folder on web site’s root and name it Filters.

   
   
   (Figure 1. - Filters folder on Solution Explorer)

4. Add a new Class file and name it TraceFilterAttribute.

5. Delete the TraceFilterAttribute class declaration from the file.

6. Inside the namespace declaration, use the attribute code snippet to create the attribute structure.

   

   (Figure 2. Using the Attribute code snippet). 

7. Name your attribute (using the snippet) TraceFilterAttribute and make it inherit from the ActionFilterAttribute.

   [AttributeUsage(AttributeTargets.All, Inherited = false, AllowMultiple = true)]
   public sealed class TraceFilterAttribute : ActionFilterAttribute
   {
   }

8. Copy and paste the code below inside your class declaration

   public override void OnActionExecuting(ActionExecutingContext filterContext)
   {
           StringBuilder builder = new StringBuilder();
           filterContext.ActionParameters.ToList()
                                         .ForEach(a => builder.AppendFormat("{0}:{1}; ",
                                                                            a.Key,
                                                                            a.Value ?? "{empty}"));
           var parameters = builder.ToString();
   
           var message = string.Format(CultureInfo.InvariantCulture,
               "{0} {1}.{2} => {3}",
               filterContext.ActionMethod.ReturnType,
               filterContext.Controller.GetType().Name,
               filterContext.ActionMethod.ToString().Replace(filterContext.ActionMethod.ReturnType.ToString(),
                                                             string.Empty)
                                                    .Trim(),
               string.IsNullOrEmpty(parameters) ? "(void)" : parameters);
   
           this.logger.Debug(message);
   }

9. The Logger used above is using Log4Net, which provides and easy and configurable way to do logging.
   
   
10. In order to configure the logger (once you have added the reference to Log4Net) copy and paste the following to your section declaration in your web.config.

    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" requirePermission="false"/>

     
11. Now include this other chunk of XML before the </configuration> tag.

    <log4net>
      <!– The DebugFileAppender writes all messages to a log file–>
      <appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">
        <file value="logfile.txt" />
        <appendToFile value="true" />
        <rollingStyle value="Size" />
        <maxSizeRollBackups value="-1" />
        <maximumFileSize value="50GB" />
        <layout type="log4net.Layout.PatternLayout">
          <conversionPattern value="(%date) [%-5level] %message%newline" />
        </layout>
      </appender>
      <root>
        <!– add other appenders here and the log messages will be sent to every listed appender –>
        <appender-ref ref="RollingLogFileAppender" />
      </root>
    </log4net>

     
12. In order to consume the logger using Log4Net copy and paste the following code inside your class declaration

    private ILog logger;
    
    public TraceFilterAttribute()
    {
        XmlConfigurator.Configure();
        this.logger = LogManager.GetLogger(typeof(TraceFilterAttribute));
    }

     
13. Now that we have built the attribute, let’s apply it to the Index() method on the HomeController.cs . Your code should look like this:

    [TraceFilter]
    public ActionResult Index()
    {
        ViewData["Title"] = "Home Page";
        ViewData["Message"] = "Welcome to ASP.NET MVC!";
    
        return View();
    }

14. Press F5 and you will see the default MVC home page.

     
    

15. Now go the web application project directory and look for the logfile.txt.

16. Open the logfile.txt, it should look like this

     

17. That’s it , you’ve built your own Action Filter Attribute.

One more little  trick

You might want to turn this sample into something for real, there’s a trick that will enable you do the tracing just if debug is enabled. All that you have to do is surround the OnActionExecuting method body with the code depicted below.

if (filterContext.HttpContext.IsDebuggingEnabled)
{
    // The method body goes here.
}

Now, your attribute will log data just if the Debug mode is enabled on the web.config of your application.

<compilation debug="true">

Conclusion

We’ve learnt how to develop a custom Action Filter Attribute. This is a very powerful and cool feature of ASP.NET MVC. This enables you to do logging, tracing and exception handling. I love this approach of doing AOP with Interceptors and the most that I like that is built in to the technology. There’s unlimited power on this, but remember a great power also means a great responsibility.

thanks,

~johnny

While attending some CMMi courses that we held at Southworks, and reading some papers about re-work written by Watt Humphrey and the CMU-SEI crew, I started thinking about how to avoid rework and what do I do to avoid re work while coding.

I realized while asking myself a couple of questions and analyzing the code review results for the reviews I conducted that most of the people make the code work, check the code in and then start caring about the quality of that code. For example most of the people check in code that doesn’t meet the code standards and then they do another check in in order to fix those.

I came up with 10 do’s and don’ts while coding that helped me understand how to avoid rework and ensure the health of our deliverables on every check in.

10 Do’s and Dont’s to avoid quality rework

These do’s and don’ts aren’t a silver bullet but they may help you as a strong starting point for avoiding rework on quality related subjects.

Do check-in often

As Alex always says Software Development is a team sport played by talented individuals. While you keep your code in your local machine you’re also putting a barrier between your work and the rest of the world’s work. Doing check in often helps you on integration, avoiding conflicts and even better gives the team visibility on where are you in terms of what you committed to do. In the other hand if you don’t commit often, be prepared to spend half a day fixing the code to avoid conflicts.

Do run StyleCop each time you modify a source code file

Code Standards are something big to be treated on another post by itself but as summary I’ll say that in Southworks we chose the working software over the comprehensive documentation as the Agile Manifesto states.

We have chosen to use Microsoft’s StyleCop to validate our code standards. Most of the code that we write often goes public, and it’s important to demonstrate that we follow a single line of thinking and the code has signature that differentiates it  from others code but also that the code is written in the same way by all the developers on the company.

In order to accomplish this, is as simple as doing right click on the source code file in Visual Studio and then Run Source Analysis. It won’t add an overhead to your regular coding routine but will ensure that the code is written on a consistent fashion the first time.

How to run source analysis

Do run Code Analysis prior every check in

Code Analysis (a.k.a FxCop) is the tool that validates the best practices of the Microsoft.net Framework. It’s based on the book written by Brad Abrams and Krzysztof Cwalina. The best practices described there were ported to an application known as FxCop.

Following Code Analysis guidelines ensures that our code is leveraging the Microsoft.net framework in the best way it can be done. And the same as Style Cop (a.k.a Source Analysis) it can be done by doing right click on an assembly in Visual Studio and then choosing the Run Code Analysis option from the context menu.

Again, doing this the first time is better than reworking the code and re committing to the main line twice in order to do it and then to fix it.

How to run Code Analysis.

Consider branching out code that may introduce risk to your deliverables

This is pretty obvious, sometimes you think a problem can be solved using some kind of approach that might have an impact on others work. The solution there is to branch the code out and don’t introduce the risk while you’re not sure that this will be the final solution or at least that your solution works.

Why is this? Some people might choose to keep it outside the source control but experience tell us that no source control will turn into something painful if something happens.

I’ll write another post about GIT which leverages this by having a local repository for each developer but that’s another story.

Do not forget the commit message

Look at the log above what can you tell about what’s going on on the project? If you don’t include a comment, a note, a reference to a requirement or something that states what are you committing you can get your team in trouble if you have to do any rollback or review of the requirements implementation.

It’s a 1 minute thing to say what are you committing and why are you committing, that also forces you to think what problem, requirement or commitment are you closing with that check in.

Do be polite with the Integration Server

This one is loved by my friend .jpg who is our Build Server & Tooling ranger. People often get confused with the intent of an Integration Server. The Integration Server is used to verify that there’s harmony in your repository, it’s not your tool to validate your code against. You should verify your work against it but don’t use it processor cycles to do your validation work.

Our build process is complex enough that might take at least 2 minutes to build a project, people often think that is the Integration Server responsibility to validate your process. Truth to be told, the intent of the Build Server is just to verify that there’s no integration problems and that all the code follows a standard.

Although the quick feedback is the most important part of the build server, you should have in mind that is a verification of work and it doesn’t do the validation you’re supposed to do.

Do not check in prototype quality code to your main line

I won’t go further on this one, I recommend you to read I.M Wright’s post about Prototyping that he just posted. As an spoiler I can tell you that the title gives a clear message “My experiment worked!”.

Do not check in until all tests pass

This one seems pretty obvious, I wrote a post about TDD last week and most of the people nowadays are adopting this practice. The important thing and a killing feature of TDD is that you are a click away of doing regression testing on all the code and check that nothing got broken with your changes.

Sometimes you get green on yours and then just wait to the Integration Server or another developer to complain about your work. This is the case where you should be polite not only with the integration server but also with your co-workers making sure that nothing is broken because of your changes.

NOTE: If you are running a huge solution with thousands of tests you might want to run just those hundreds tests on the impact surface of your code.

Do ad-hoc peer reviews to validate your logical thinking

Two pair eyes of eyes see better than just one. That’s the rationale behind this point. Developers (and I include myself on the subset) love to put their headphones, enter their matrix kindda world and write code as the music moves forward. But as I said on the first point Software Development is a team sport and a team that cooperates is by far more candidate to win.

Do not wait until the formal Code Review comes up to you and you have to explain what you’ve done. Just put pause on iTunes for 5 seconds, ask your nearest team member (doesn’t matter his expertise always there’s something good to learn from our peers) what does he think about your idea and that’s it. You just had a peer review.

Do be consistent and disciplined while applying the nine practices above

Now you know it, but the practice makes the master. Fasten your seatbelt and get ready to improve your personal development process. You and your team will be happy to share a principles in terms of quality so your code is nice, easy to maintain and well written.

And your team as all the famous painters will have a code signature that will distinguish yourselves from the rest of the mere mortals.

And in the end….

One thing that I’ve learnt from people that have years working on Software Quality and people that I met like Eric Brechner (Microsoft Engineering Excellence Director) is that the most important thing when talking about Software Quality is defining done. If you follow these simple steps you will be closer as a team to produce code in a standard and consistent basis while starting to define the meaning of done for code.

thanks,
~johnny

Almost form the beginning of my blog,  I started writing about Test-Driven-Development [1] [2] [3] [4] [5] that now was renamed by the Agile Gang  as Behavior Driven Design. That new name is kind of cool and fancy (Oh these agilists always looking for new adepts) but there’s a truth and a strong rationale behind what they call BBD.

I wrote this post after a long time practicing TDD, this Truths and Myths are based on my personal experience and the knowledge acquired with time. You might disagree with some, you will love others, but this post is an exercise for my self trying to dump all what I’ve learnt in these years practicing TDD.

I’ve divided the post in three parts:

• Myths. These are the things I heard while working as consultant, stuff that showed up while discussing with colleges or things that came up while discussing with friends.
• Truths. These are almost the same as above but mostly positive things that demonstrate that there’s value on applying this practice.
• My TDD Zen Garden. This are tips and tools that I used while doing TDD, they’re not mandatory or maybe part of the official practice. There I’m just sharing my personal tips and thoughts.

5 Myths about TDD/BDD

Myth 1: “Tests are for testers”

That’s my favorite one, when people don’t understand TDD or are just too lazy to write the tests they claim for the “Test is for testers”. Although the name has the word test, it doesn’t necessarily means that your testing as a tester would do it.

Myth 2: “Oh buddy, if I wrote them it’ll take me twice”

Ok some people think about writing the tests first as some kind of time consuming, useless, non-sense activity. Those that think like that are often the ones that never thought or read about Re-work  there are some great papers from Watts Humphrey and CMU-SEI Crew about this. If you had the tests to validate and verify your work, you’re one step closer to avoid rework.

Myth 3: “I’m bug free , I had 100% Code Coverage”

This might be controversial,  but after doing some deep thinking on this and listening to Scott Hanselman podcasts, I realized that 100% Code Coverage isn’t the best. Code Coverage is a negative metric, it’s about where we should focus are testing intentions based on what we’ve left uncover. As far as I researched, there’s no tool to measure code coverage by paths (this can be fairly accomplished by hand). So 100% isn’t bug free.

Myth 4: “If I apply incremental design techniques based on TDD, I end up just with a huge test method”

That’s more than a Myth, that’s a mistake, when doing TDD it’s always a matter of starting to cross tests from the lists. People often think that as the method to be tested evolves the original test evolves with it. Well, for me it’s that as you move forward you add new tests. So your fixture becomes a living, and breathing component documentation.

Myth 5: “Doing TDD covers our team from doing functional testing”

That’s something that I heard too much, in this case the Myth or assumption is not about people using it wrong, this is about misunderstanding its power. TDD as I titled this post is about letting the design to emerge by expression on a bunch of lines of code our intention for that component. Also the testability for components (the new buzz word) will help us to understand coupling (WARNING! this also might led you to over engineering).

5 Truths about TDD/BDD

Truth 1: “The TDD motivation is about writing clean code that works”

By writing the code needed just to make the test passes you are ensuring that your code fulfils just the test requirements and also that there isn’t dead code, unwanted code or other sort of code horrors.

Truth 2: “TDD outcome is a living breathing documentation for the component”

That’s one of my favorites things about Test Driven Development while you’re writing the tests your expressing the rationale behind those lines and more than that the intended use. When a new developer arrives to a project, if you can hand out a couple of fixtures for him to look at, you’ll probably get him up on speed faster than it would take if he just have to read the code.

Truth 3: “By applying TDD you end up with well factored code”

Some people think about all the decoupling stuff associated to TDD as some kind of black art or magic. Truth to be told, this principle applies painless and it’s harder to realize that you’re doing it than doing it. While you are expressing the intention and how the object should be have you’re defining almost ad-hoc what it shouldn’t do. Writing tests is determining responsibilities for components and when you define those, you’re already decoupling your objects.

Truth 4: “Doing TDD increases the motivation”

While setting micro-goals to yourself and accomplishing them you start to fell better, think of it as 3 years projects, with thousands of man hours to be invested. How do you get the fell of moving forward and don’t fall on the depression of writing code that is going nowhere. Well by simply setting a test for your code, you start to fell confident about what you’re doing and that gets you the feeling of progress as the green lights for your test cases are on.

Truth 5: “There’s no silver bullet”

This might be the most discouraging truth I’d ever written but the true doesn’t hurt. You may get all the benefits of doing TDD but you still need peer reviews, code reviews, analyze your code against formal computer science metrics of complexity and coupling, and all that stuff. I felt like you maybe be feeling when I read the same title on the Mythical Man Month, I thought about that book about the great software engineering problem solver but Mr. Brooks Jr. was pretty clear and I’m agree, there’s no silver bullet and TDD is just another great practice to use in the fight against the bug count and defect ratio.

My TDD Zen Garden

These ten tips are what I call my TDD Zen Garden, they consist in 10 things that use, think about or realized while practicing TDD for about +4 years. As I said on my last Truth (”there’s no silver bullet”) these are just practices, and I encourage you to challenge them, try to defeat and destroy them, because at that point you’ll have something to teach the rest of the world or just me, and that idea fight is really enriching.

Tip 1: “Write tiny and focused test methods that check only one aspect of your code”

If you method can’t be tested with 2 or 3 assertions, that’s code smells. The rationale behind this is to write method with less responsibilities and generate a well factored code.  A single method might take 2 or 3 test cases to test the alternative paths but a well written method will just need one to test it’s core functionality.

Tip 2: “Avoid fragile assertions on human readable text such as error or flash messages”

Try to write your tests (and your code) in order that it can be checked without doing strange things, like converting case or stuff like that. Tests are used to verify and validate that the code does what it needs to do. Think of it as an equation, don’t try to test things that might become messy.

Tip 3: “Use Code Coverage Tools”

Although all the things I said about Code Coverage percentage being a negative metric, it’s useful to know what aren’t you testing. Some people might think that when you find a line that isn’t tested what you should do is to write a test that passes over that line. My approach is a little bit different, if I find something that isn’t covered I just go and delete it. If that was something that I really need it will appear again when the time is right.

Tip 4: “Keep the test logic inside the test method”

As we discussed previously on this post, test are living and breathing documentation for the component. Do not try to refractor it in order to reuse, test methods aren’t intended to be productive code, they’re documentation and development support. Do no save space or try to reduce its numbers of lines, keep it tight, make it atomic and reduce its dependencies. That will make it more readable for people.

Tip 5: “Use mocking frameworks”

This is because mocks (pieces of code used to simulate another component) are just for testing proposes. People often fall in writing huge mocks, that often do too much and even worse they end up testing them.

Mock Frameworks, are useful because all the interaction logic stills inside the test method and as I said before the more information you give inside the test case the better. I clearly don’t have any favorite one, but MoQ and Rhino Mocks are two that I often use and mostly recommend.

Tip 6: “Don’t rely on context data for your tests results”

I often heard that some test are failing because of data that needs to be on the database isn’t there. I prefer to do the insertion and deletion and everything that needs to be done on the test method I don’t rely on existing data because that will you to a fragile assertion (See tip #2 for more info).

Tip 7: “Use Transactions instead of Tests Databases”

People often create bunches of databases to test against, I personally prefer to wrap my whole test inside a transaction. That let’s me play around without screwing up the database and even better I don’t fall on relying on Context Data for my tests. (See tip#6 for more info).

[TestMethod]
public void MyTestMethod()
{
    using(TransactionScope ts = new TransactionScope())
    {
        //write all the test logic here.
    }
}

When the using scope finishes, it will automatically rollback the transaction.

Tip 8: “Make your test cases atomic”

Do not rely on other tests to be running in order to write your test, do not make any tests dependant to other. Write you tests as if they were intended to run on isolation. This will help you troubleshoot a problem when some test fails.

Tip 9: “Do not hesitate on long tests names”

I’ll continue insisting that test are living and breathing documentation of the project, so avoid naming your tests as ShouldThrowException or something that doesn’t provide an insight of what’s going on to the reader.

[TestMethod]
public void ShouldThrowExceptionWhenInvalidCustomerNameIsPassed()
{
}

The name depicted above is an example on how I like tests method to be named.

Tip 10: “Be consistent, methodical, and patient”

It happens event to the best developers and TDD practitioners that at some point of time they go nuts and think about throwing all the fixtures and crack code as fast as they can in order to see their new creation moving. Be patient, consistent and methodical, follow always the process. Software isn’t just built and thrown away, people will have to maintain your baby so please be considered and be thoughtful and polite when your self because at some point (even the best developer) you will have to troubleshoot your code.

thanks,

~johnny

We’ve finally released the Patterns & Practices Repository Factory. This release contains the source code at the completion of the patterns & practices work on this project. As we said before now the destiny it’s on your hands.

The work done includes:

• Independent of Service Factory tree
• Generic code has been moved into a separate assembly instead of being generated every time
• Generated code has been placed in different folders to keep the underlying goop out of the way
• Interfaces are generated for the repositories, so you can provide multiple implementations of the repository
• Auto-mapping of entity fields and stored proc parameters
• Recipe inputs are stored across runs so you don’t have to reenter everything every time you run
• New, easier to use and understand UI screens

and many other additions…

Requirements

To compile this package, you need:

• Visual Studio 2005
• GAT and GAX July 2007 CTP

The package will also compile and run with the earlier GAX Feburary 2007 CTP.

If you wish to compile and run the unit test projects, you’ll need Visual Studio Team Test, Team Developer, or Team Suite editions.

Compilation and installation

Open the DataAccess Guidance Package.sln file and compile.
The easiest way to install the package is to compile the setup project and run the resulting MSI. The guidance package requires a registry key in order to find various support DLL’s needed at runtime. The MSI will create this key for you.

If you wish to manually register and use the guidance package, this registry key is:

HKEY_LOCAL_MACHINE\Software\Microsoft\patterns & practices\Repository Factory

Create a string value named "EntlibBinaryPath" and point it at a directory that contains the following DLLs:

• Microsoft.Practices.EnterpriseLibrary.Common.dll (available in Entlib 3.1 and included in the Lib folder in the drop)
• Microsoft.Practices.EnterpriseLibrary.Data.dll (available in Entlib 3.1 and included in the Lib folder in the drop)
• Microsoft.Practices.ObjectBuilder.dll (available in Entlib 3.1 and included in the Lib folder in the drop)
• Microsoft.Practices.RecipeFramework.Extensions.dll (Included in the Lib folder in the drop)
• Microsoft.Practices.Repository.dll (compile from source)
• Microsoft.Practices.RepositoryFactory.SchemaDiscovery.dll (compile from source)
• You can get both (supported release code and/or Msi) go to: http://www.codeplex.com/RepositoryFactory/Release/ProjectReleases.aspx?ReleaseId=7429

thanks,
~johnny

Hi! First of all I want to recognize my fault since the last two weeks I didn’t made my weekly-post. I’ve been very busy completing the remaining stuff from Repository Factory. That mostly includes the rework of the Create Repository recipe.

Now it’s a wizard!

As you might know our core in this factory was the generation of Repositories, Chris figured out that it was too hard to do (as it was designed). So we’ve converted the addition of operations to the repository from an ugly screen to a wizard.

Operation detail

Improved parameter mapping

Summary

I’d like to close this post saying thank you. All the improvements done in this project have been community-driven. As I insisted in all the posts about the Repository Factory, the community managed the course of the actions by prioritizing, voting, providing feedback, and reading these posts. Now it’s our call to action: Wanted- Project coordinator and members. Yes, now you have the opportunity to be a developer for this factory!.

From my side I want to thank the community members like BennyXNO and David Hayden whose continuous feedback help us a lot while doing the factory. I’m really happy to work with Chris Tavares who is a great developer and was a great Project Manager.

thanks,
~johnny

As I promised when we launch this project, I’m reporting each week the progress that we’ve accomplished in the past week.  This week has been mostly QA and a highly valuable improvement.

Improved wizard reentrancy

Last week we’ve accomplished wizard reentrancy for Create repository recipe, but we had a bug where we’re not persisting the Identity for each operation (when it applies). Now we’ve added the Identity to the recipe state file as depicted below.

Fixed mapping duplication

When you had a stored procedure that uses a parameter and it’s also included on the as ReturnValue it appear twice in the mappings. Now we’ve fixed this by adding the parameter direction on the recipe state file. How now a parameter looks like

<parameter propertyName=”Name” parameterName=”pty_Name” parameterDirection=”6″ />

Enabled recipes to run on IIS hosted project 

We’ve done a small fix to the GetConfigurationAction that allows you to run the recipes that uses configuration file on web sites that are not on File-System.

Place generated code on folders by entity

This was the major improvement for this week. Previously when you generated a repository, all the files that comes along with it where added to the root of the Data Access Project.  Chris figured out that once we’ve the RepositoryFactory.Create you no longer needed to be aware of those file and generated repository implementation neither. Now this is how your data access project will look like.

This improvement has a couple of benefits:

1. If you want to get rid of the generated code and maintain just the interface, now you just have to remove the {EntityName}RepositoryArtifacts folder.
2. All the generated code is encapsulated in a single folder, so you don’t have to be aware of how many files and the implementation details since you’re relying on the factory.
3. In addition to the RepositoryFactory.Create() this will keep your projects not aware of where the generated files are.

Finally, if you use the generated stuff as showed below, you’ll just have to include a Using to DataAccessProjectNamespace.

using ClassLibrary17;
using Microsoft.Practices.Repository;

public static class Class1
{
    public static void Main()
    {
        IPersonRepository repository =
                                RepositoryFactory.Create();
    }
}

This week we’re probably tackling the rework of the UI. We want to make the factory more usable, since we consider the usability as a core part for software factories.

Summary

We finished another week, all the tackled issues were not invented by us, they are community requests. We’re listening to you, please feel free to provide feedback in our community site. We work on the improvements starting with highly ranked ones, you have a chance to influence the course of the project.

thanks,
~johnny