DDD IoC Moq MVC ... Time to catch up

After I joined HP, I hadn't realistically had the time to keep up with the changes to the .NET platform in regards to frameworks, design patterns, etc. I'm between development cycles right now (going to be doing a custom SharePoint 2010 project that I'm looking forward to), so I figured this was the best time to get back up to speed. My current interest is in learning more about Domain Driven Design (DDD), the Repository Pattern, Inversion of Control (IoC), Microsoft ASP.NET MVC2, Microsoft Unity2, Microsoft Entity Framework 4 (EF4) and Moq. Just some quick links for myself ...

• http://www.martinfowler.com/articles/injection.html


• http://domaindrivendesign.org/


• http://elegantcode.com/2009/06/28/elegant-code-project-structure-purse-fight/ (this is just a reminder for me for folder structure layout)


• http://en.wikipedia.org/wiki/You_Ain


• http://msdn.microsoft.com/en-us/library/ff649690.aspx (SharePoint list using Repository pattern)


• http://www.primaryobjects.com/CMS/Article108.aspx (just a simple 'oh-yeah' example)

Just some quick code for myself ...

    [TestClass]
    public class ContactTest
    {
        #region Private Variables
        private Mock<icontactrepository> mockRepository;
        private IContactService service;
        #endregion

        #region Test Initializations
        [TestInitialize]
        public void Initialize()
        {
            this.mockRepository = new Mock<icontactrepository>();
            this.service = new ContactService(this.mockRepository.Object);
        }
        #endregion

        [TestMethod]
        public void UserCanGetListOfContacts()
        {
            // Arrange
            Contact mockContact = new Contact() { ID = 1, LastUpdated = DateTime.Now, LastUpdatedBy = "Brandon", Name = "Brandon Lind", Ranking = 1 };
            this.mockRepository.Setup(m =&gt; m.GetAll()).Returns(new List<contact>() { mockContact });

            // Act
            var result = service.GetAll();

            // Assert
            Assert.IsInstanceOfType(result, typeof(ICollection<contact>));
        }
    }

Typed datasets are good ... in small quantities

Today I had to throw together an app that would allow a fine grain comparison (i.e. more control than VLOOKUP) of values between an Excel spreadsheet and a SQL Server. Pretty standard stuff I know, but this was my first pass at doing so using typed datasets for the SQL end (I like compile time checking), and pretty much datasets in general. I'm more of a Business Objects type of guy.

I have to say, it was actually really easy to use. The only thing holding me back from using them more often in my full scale app is the separation factor of the DAL from the BLL and not having a circluar reference. I typically use 3 classes: An object class (which is really just a dummy set of classes containing class properties), Data Access Class and a Business Logic class. I think it's possible to separate the typed dataset from the table adapters, but it wasn't something that's easily discerned/apparent. Plus with LINQ to SQL ...

Just for my reference ... to add a datarow from one datatable to another, use DataTable.ImportRow(datarow);