Contents tagged with ASP.NET

  • OOA/OOD is not Domain Driven Design

    Analyzing functional requirements for your application to capture what and how your application should work is not necessarily domain driven design. Yes, both techniques leverage the domain model pattern to structure responsibilities in code.

    My tip is to pay close attention to who the “real” domain expert, business user or sponsor is.

    Translating use-case documents into a domain model representation doesn’t imply that you’ve captured domain concepts in code. Unless the use case writer is a domain driven design enthusiast.



  • DEVs and DBAs Unite

    Some of my clients have/had challenges embracing object-relational mapping data access API’s. I’ve experienced this with introducing Neo, IBATIS, NHibernate, LLBLGen Pro, LINQ to SQL and Entity Framework in projects for our clients.

    As with most things in our field this hasn’t much to do with the technology choices we make. Better collaboration is the key here. I’m glad that Patterns & Practices acknowledges that guidance in this area could help these two groups to leverage each others strengths. I’m confident that enabling a better understanding of both domains will improve the adoption of Microsoft’s data access api’s in the future.

    Please give your feedback on the Data Access Guidance wiki.


  • Application Architecture Guide, 2nd Edition

    The Patterns & Practices team is working on the upcoming release of its Application Architecture Guide, 2nd Edition which should arrive late summer this year.

    One of the areas the team seems to be concentrating on is Domain-Driven Design (DDD). A how to guide is publicly available since January. Skimming through the comments it appears that developers/customers are challenging the original authors how to apply the ideas and experiences published in books (Evans, Fowler, Nilsson).

    Implementing a domain model in a general purpose language (Java, C#, etc) is challenging. Key to success is to have as little distractions (from the development platform) as possible. The set of design principles and patterns will help to accomplish this goal. I learned that, after discussing ideas with attendees during my “Applying Domain-Driven design in .NET” talk at SDC 2007, there’s a strong focus to overcome the technology use/constraints in applying DDD in our target platform.

    My advice for the Patterns & Practices team is to focus on:

    Which principles and patterns should be applied (as a coping strategy) for the distractions in the development platform?

    Please realize that this is different from guidance on how to implement DDD-patterns with the .NET platform.

    Language workbenches are well underway to completely change the way we do programming, so we might not this guidance anymore ;)


  • Why ASP.NET MVC?

    I love the summaries on InfoQ. Earlier this week I received a presentation by one of the customer’s developers. Basically they used MVC for a spreadsheet type application. The answer to the question “what made you guys decide to use MVC for this applications” was interesting “because we wanted to learn something new, and because it’s cool!”. That’s when my architect alarm bells start ringing. What I’d like to add to the whole ASP.NET MVC discussion are these two questions:

    1) Why do you need an MVC in your application?

    2) Why is the, compared to other alternatives, ASP.NET MVC the best MVC solution for your application/environment?


  • Entity Framework Tutorial

    You don’t know anything about the Entity Framework or didn’t get around installing it on your box and pour the Northwind data onto a screen? This book could give you a great jumpstart into the Entity Framework. There are a lot of Entity Framework books coming your way, so why should you buy a copy of the Entity Framework Tutorial by Joydip Kanjilal? Packt was so kind to send me a copy, but you can always try to get a free copy as a blogger, reviewer or educator. Otherwise I can definitely advise you to get the ebook and use it to inspire your colleagues.

    Because that is what this book is great for: convincing co-workers to start thinking and experimenting with the Entity Framework. Many development teams are still handwriting their data access code.

    In the first chapter you’ll learn the key concepts and get an overview of the Entity Framework’s architecture. In the second chapter you’ll learn how to get started with the Entity Data Model and bind some data to a GridView data control. From this point on you’re set to build RAD applications!

    It continues with getting down to the nitty gritty details in the Entity Data Model. This is not the strongest part of the book. None the less it provides a great way to learn more detailed concepts driving your Entity Framework based solutions. Stored Procedures are up next together with the lower level API’s in the Entity Framework namely Entity Client and Entity SQL. You’ll learn more about executing CRUD operations against your database with the Entity Framework.

    The book successfully saves the best for last; LINQ to Entities and the Object Services Layer. I recon 90% of your projects will utilize both API’s. Creating queries, execution and concurrency conflicts are interesting subjects you’ll learn more about. This book only gives a glimpse of these subjects which each have enough going for them to fill a 200+ page book.

    I don’t see the need for a chapter on ADO.NET Data Services but it’s included in the book.

    Don’t feel like skimming through MSDN and knot together the loose ends? Don’t feel like reading through Julie's excellent 800+ pages? This is a great alternative. I use this book to inspire people about the Entity Framework by letting it floating around the office. For in depth knowledge and to master the Entity Framework’s complexity you’ll be better of with Julie’s Programming Entity Framework.


  • SDN Conference 2008

    The Software Development Conference 2008 was great. I gave two talks this year. The first was in a chalk & talk format titled “Understanding the ADO.NET Entity Framework Architecture and its Implications on your Application Architecture”. The audience gave me a pretty good workout. I promised that I’d share my whiteboard sketches on this blog. I’ll try to reproduce them and post an update somewhere next week.

    The other talk was titled “Technology Deathmatch: LINQ to SQL vs. ADO.NET Entity Framework” together with Alex Thissen. Preparing and delivering this session together with Alex was a brilliant experience. With both technologies moving forward in future .NET versions we’ll definitely pick up the fight along the lines. Stay tuned :) or better Alex you’d better be prepared.


  • Business of Today is the Infrastructure of Tomorrow

    Regardless of whether I agree with Jeffrey Palermo in his answer to the question: How do we ensure the long-term maintainability of our systems in the face of constantly changing infrastructure? Jeffrey first gives his definition of long-term maintainability and changing infrastructure. With the definitions his answer to this question is: Don’t couple to infrastructure.

    Two questions came across my mind. First what exactly is infrastructure? In other words is the infrastructure of today the infrastructure of tomorrow. I see a trend where the business of today is the infrastructure of tomorrow. Service Orientation is one of the big drivers in this area where services covering certain aspects of the business become a commodity, because certain products and services become a commodity. I also see today’s infrastructure becoming more and more transparent. Significant investments in open standards are starting to pay of.

    Jeffrey’s article takes on the aspect of object-relational mapping from a particular viewpoint. Frans Bouma commented that object-relational mapping frameworks are incorporating more advanced functions which make it harder to decouple important business aspects of our applications from these framework and tools.

    In one of my previous lives, in the industrial automation, it was very common to enable transparency through standards and regulation. I consider a nut and bold to be very standardized. Taking this analogy further aren’t object-relational mappers the nut and bolds for our applications? What about standardisation?


  • Putting More into Data and Less in Code

    What does it mean to put more of our applications into data and putting less in code? Are WCF and WPF early examples of this thinking in which we put more and more of the application in configuration. It would be interesting to learn more about what Microsoft, from their perspective, considers to be an “application”.

    Looking forward to the PDC where we’ll definitely get more information about this new declarative programming language code-named, ‘D’. Read more here.