CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeff Lynch [MVP]

Everything E-Commerce!

February 2007 - Posts

  • Commerce Server 2007: Development Tip #6 - Adding Items to your Basket

    I've revised the code presented in this post after a reader pointed out the (seemingly obvious, but I never saw it) flaw in my code. It's always important to have someone checking your code occasionally. Special thanks to Tim Bond for pointing out this error.

    Tip #6 - Adding Items to your Basket

    The basic funtionality of the LineItem class has changed little from Commerce Server 2002 and adding an item to your basket works pretty much as it did in the previous version.

    The first thing to do is create a new LineItem instance, set the required and optional (weakly-typed) properties and then add the LineItem to the OrderForm's LineItemCollection.

    As with every action taken in the Basket, you should always update the Basket and run the appropriate pipeline as shown here.

    In Commerce Server 2007, it's also important to remember to dispose of the PipeLineInfo object to ensure that resources are released in a timely manner. Also, since Commerce Server 2007 now supports multiple "named" baskets that are active at the same time, you may need to extend your code to accommodate this new feature.

  • Visual Studio Team Edition for Database Professionals: Schema View Synchronization

    UPDATE! 

    Gert Drapers [MSFT] has posted a much more thorough explanation of refreshing and resyncing the schema view. Take a look!

    To Synchronize or To Refresh?

    Here's a quick tip for those of us using VSTEDP (DataDude) for database development and TFS (Team Foundation Server) for source control.

    You may occasionally see a yellow message stating "External file change, resynchronization required..." when you open a large solution, perform a "get latest version (recursive)" and switch to the schema view. I'm assuming this is a normal behavior since the local schema database may be out of sync with the object scripts just downloaded from the TFS server. If I remember correctly, the DataDude team decided not to "resync" automatically since it may take some time to accomplish on a large scale project. Unfortunately, it's not immediately obvious how to do this unless you mouse over the "Synchronize" icon as shown below:

    No, this is not a "Refresh" button as the icon suggests, it's a "Synchronize" button and will bring your Solution Explorer view and Schema View into sync! Keeping these two views in sync is critical since the Schema Compare and Data Compare functions use the local schema database and not the SQL script files.

    I know the DataDude team talk about the "one version of the truth" in database development but in reality there are two versions, one in the script files and the other in the local schema database. It's important to keep these two versions of the truth in sync!

    Technorati Tags: , ,

  • Visual Studio Team Edition for Database Professionals: Where to Find Answers!

    I know this has been posted before but the very best place to find information on Visual Studio Team Edition for Database Professionals (DataDude as Gert Drapers calls it) is on the Database Professional Team Center web site! There are a lot of links to great video content, on-demand webcasts, technical articles and blogs from the team members.

    The other great resource for questions, issues and support is the Visual Studio Team System - Database Professionals Forum on MSDN. The DBPro team actively participates in this forum and it's a great place to get answers!

    Technorati Tags: , ,

  • Team Foundation Server: Project and Source Control Structure

    One of the things I like best about Team Foundation Server is the ability to structure our entire "data warehouse solution" as a TFS Project and to match this structure in Source Control. For us, this includes our Visual Studio Team Edition for Database Professionals (VSTEDP) projects and any other related Visual Studio projects such as SQL Server Integration Services (SSIS) and SQL Server Reporting Services. 

    We had done a lot of thinking and research about how best to organize our database solutions in Team Foundation Server and after a lot of trial and error, settled on the structure shown above. We decided to store our entire data warehouse solution in TFS using a "solution centric" model where all the inter-related Visual Studio projects are divided logically by project type since this helps us break down the "solution" into small, more manageable areas of work. We also wanted to be able to branch the entire "data warehouse solution" when we need to deploy a new major version (such as described in our recent case study) but still be able to employ continuous integration practices when adding features or bug fixes to the existing solution. And since we're a pretty small development team, we wanted to do this with a minimum of time and effort.

    One of the great things we've found using this "solution centric" approach is that it helps remind us how changes in individual VS projects affect the entire solution. Take for example when we decide to pull some additional information from our ERP system into the data warehouse for an existing report we are working on. This (relatively small) change will require a change to one or more VSTEDP projects, SSIS projects and SQL Reporting Services projects with each change building upon the previous change (DB --> SSIS --> SQL Report). By structuring our TFS Project and Source Control in this manner, we are visually reminded of how all the pieces fit together in our solution and we are able to use the Scenario and Work Item Tracking features of TFS to manage the entire "development workflow" even though it spans multiple VS projects. We can test our changes through each step of the development workflow as well as at the "solution" level before we deploy this to our production servers.

    The good news is that this structure works really well for us and is very easy to manage. The bad news is that we tried about ten different structures before settling on this one and all these previous "trials" are still stored (although hidden) in Team Foundation Server. Hopefully when we upgrade to the next release (TFS Orcas) we'll be able to "destroy" all this obsolete stuff and move forward with a less cluttered TFS server.

    Lessons I Learned:

    • Structure your TFS Projects and Source Control at a high level to follow your corporate solution or application.
    • Use your TFS Project and Source Control structure to make it easy to manage change because change happens all the time.
    • Setup a "sandbox" instance of TFS where you can try different project and source control structures. Don't do this on your main TFS instance until the Orcas release.

    Technorati Tags: ,

  • Team Foundation Server: Source Control Video

    I watched a really great Channel 9 video yesterday (filmed by Brian Keller and starring Doug Neumann) about Team Foundation Server source control branching and merging strategies. Doug is the TFS Group Program Manager and does the best overall job explaining TFS source control branching and merging that I’ve seen or read to date. This is a very complex topic but Doug does a great job simplifying the concepts and explaining the pros and cons of each approach. Ever since I started using TFS for source control this area has bugged me and Doug's video goes along way to helping me decide which approach best fits our development efforts. If you're using Team Foundation Server, this video is a real gem!

    PS: It's also pretty amazing to see someone as technically "deep" as Doug do so well in front of a camera. Way to go!

    Technorati Tags: ,

More Posts

This Blog

Syndication