Architectural Musings

Master Pages with NVelocity and ASP.NET MVC

2009-06-09T01:57:00.001-06:00

Not too long ago I was digging around for information on how to use the NVelocity ViewEngine for ASP.NET MVC. The MVCContrib project on CodePlex currently does not have any documentation, and it took some digging around in the source code and samples to find the solution. Master pages with NVelocity for ASP.NET MVC are not quite as fully featured as with standard .aspx views, however they are possible in a basic form.

The NVelocity view engine for ASP.NET MVC supports a #parse() command which may be used to render any other NVelocity view. You can explicitly state the view you wish to render, such as “shared/header.vm”, or specify the variable $childContent to render the child page. Unlike .aspx views, you can not create multiple content place holders in the master page, each of which can be populated in your child page. But for the most part, that is ok, because with the #parse() command and partial view rendering you can pretty much take care of any composability needs in your NVelocity views anyway.

<head>
  <title>My Page with Master Page</title>
  <link href="$Url.Content('~/Views/Common/Site.css')" rel="stylesheet" type="text/css" />
</head>
<body>
  <div id="header">
    #parse("shared/header.vm")
  </div>
  <form>
  <div id="content">
    #parse($childContent)
  </div>
  <div id="footer">
    #parse("shared/footer.vm");
  </div>
  </form>
</body>

Stackoverflow

2009-05-23T20:27:00.001-06:00

I’ve been encountering Stackoverflow.com quite a lot lately when I search for answers to programming questions on the internet. Today, I finally signed up for a membership to the site, and I must say, its one of the nicest community sites for programmers I have ever encountered.

Stackoverflow is a refreshing blast of modern web site and community design, and quite enjoyable to use. It’s also an intriguing weave of forum, wiki, blog and something akin to digg. For those of you who are interested in sharing your knowledge, Stackoverflow offers a bunch of rewards and incentive to share. The more you help, rate, and answer questions, the more badges (rewards for achievements) and reputation you earn. The more reputation you have, the more power you have in the overall Stackoverflow community.

Which leads into another interesting aspect of Stackoverflow. It is a site for programmers, by programmers, and managed by you. There is a staff who develops and maintains the infrastructure and software for Stackoverflow, but its the community members who administer it. Those with the highest rep are granted the rights of moderators, able to edit, close, delete, and moderate the questions and posts on the site.

While I can’t say that Stackoverflow has displaced CodeProject as my primary programmers resource, it has definitely taken second place on my list of favorite developer community sites.

Give it a whirl: www.stackoverflow.com

New Water Cooled Computer

2009-05-17T13:29:00.001-06:00

Near the beginning of the year, my old motherboard up and died on me. As a result, I ended up doing a full upgrade with a new motherboard, cpu, and ram. In addition to upgrading, I also went all out and built a custom water cooling system with Koolance parts. Here are some pics and the system specs:

Motherboard	Asus Rampage II Extreme
CPU	Core i7 920 2.66Ghz @ 4.3Ghz
Memory	12Gb OCZ DDR3-1600 7-7-7-24
GPU	EVGA GeForce GTX 280
Sound	Creative X-Fi Motherboard Edition
Screen	Apple CinemaDisplay 30”
Drive Space	2Tb 4 7200Rpm Western Digital
Case	Antec P190 1200Watt Dual PSU

The water cooling system is built entirely from Koolance parts. It includes a custom waterblock for the Asus Rampage II Extreme that covers both the north and south bridge, a waterblock for the CPU, as well as two small waterblocks for the voltage regulators around the CPU.

CPU	http://www.koolance.com/water-cooling/product_info.php?product_id=755
MB	http://www.koolance.com/water-cooling/product_info.php?product_id=772
VReg1	http://www.koolance.com/water-cooling/product_info.php?product_id=736
VReg2	http://www.koolance.com/water-cooling/product_info.php?product_id=660
Nozzles	http://www.koolance.com/water-cooling/product_info.php?product_id=397
Tubing	http://www.koolance.com/water-cooling/product_info.php?product_id=171
Exchanger	http://www.koolance.com/water-cooling/product_info.php?product_id=634
Pump/Res	http://www.koolance.com/water-cooling/product_info.php?product_id=280

And here are some pictures of the system (I apologize for the quality…they were taken on my iPhone):

The Disappointment of Entity Framework

2008-11-28T02:28:00.001-07:00

I just hit the EF Design Blog again, for the first time in a few weeks. I was quite dismayed by the latest post, which was addressing one of the most important aspects of EF: change tracking. To put it simply, I’m disgusted by the approach the EF team is taking. They are not solving the problem…they are adding an API so we, their customers, can solve the problem for them. They are taking the easy way out, shortcutting the process, and ignoring the needs of their customers…by giving them more work.

I believe Microsoft has lost sight of what the real world need is for products like Entity Framework: Object Relational Mapping…bridging the gap between the relational world of tables and foreign keys, and the object world of types and references and hierarchies. I think they have become too wrapped up in trying to create a pervasive, all encompassing “data framework” that they have overstepped their bounds, forgotten how to solve their customers problems, and are now just building another bloated platform. Which is absolutely NOT what we need.

I was very excited for EF before it was released. It boasted advanced mapping capabilities, a provider model, a much richer visual designer than LINQ to SQL, and an n-tier story. In actuality, mapping is a nightmare mired in useless rules and restrictions, the visual designer is as touchy as an inmate in an psych ward eagerly awaiting the chance to wipe away manual changes, and the n-tier story is generally absent due to missing change tracking. The problem we were left with was a half-wit visual designer that needed “developer support” through manual editing of SSDL/CSDL/MSL and a cesspool of ad-hoc one-off change tracking solutions to fill in the gaps that Microsoft, conveniently enough for themselves, left gaping to meet a release date.

An here we are, eagerly awaiting news about the solutions hiding around the corner in EF v2…and the story hasn’t changed. We won’t be given solutions…we will be given the means to create a thousand solutions ourselves. Each one requiring an investment of either time or money…or quite possibly both…depending on whether we solve the problem ourselves, or wait to buy the solutions of others, or buy a solution that doesn’t solve the problem adequately enough requiring still further solutions. Either way, the real problem isn’t solved, and EF v2 is shaping up to be another wonderful round of EF v1 with a few new API’s and a fancy WF code generator.

Whoop, Whoop.

Data for Display vs. Data for Modification

2008-10-02T12:58:00.001-06:00

I have long been a fan of object-oriented programming. From the first day I borrowed a book on C++ from the local library when I was about 10 or 11 years old, I was hooked. Objects were so natural, convenient, and kept code organized. Objects could be related to other objects, objects could contain lists of other objects, and object graphs were born. Back then, and for quite some time, objects seemed to be king, and were the fundamental component of software for a very long time. Even today, objects are still a very fundamental aspect of software development. Objects and object graphs solve a lot of problems.

Object graphs don’t solve every problem, however. Sometimes, the use of a rich, hierarchical object model with rich relationships between the various participants can get in the way. Simple needs can become hugely complex when object graphs are involved. Resources such as CPU, memory, and bandwidth can become needlessly consumed when object graphs are created and passed around when only a subset or aggregation of the information contained within the graph is actually required. With the complexity of modern applications, and the need to develop them cheaply with minimal developer resources…keeping things as simple and efficient as possible is becoming ever more important.

Data for Modification

When it comes to editing data, objects are still king. Creation, modification, or deletion of data is a fundamental part of just about every application. Such operations require detailed knowledge of the “true” structure of the data being edited. Knowing the hierarchical and relational associations between the entities in a graph are critical to safely and successfully creating, modifying, or deleting the data those entities represent while maintaining the integrity of that data. Rich object graphs are the ideal mechanism to store and represent data that needs to be modified.

Data for Display

Despite the value of objects for modification, the richness and detail of an object graph does not effectively meet the bar when data simply needs to be displayed. Data is most often stored in a relational structure: tables, keys, and references to keys of other tables. Pieces of information are isolated into discreet locations, aggregated into related sets, and stored in the most efficient manner possible to save space and maximize retrieval speed.

When we display data, however, we tend to display it in ways that make the most sense to humans, and those ways don’t often mirror the ways we store data or edit data. Data from multiple tables are joined, aggregated, and reduced into a flat set that represents exactly what humans are interested in. These flat result sets are best represented, not with a structured, composite object graph, but with a simple table, or a collection of simple non-related, non-structural objects. Simple, flat structures with minimal relationships are compact, efficient structures that may be quickly transferred from one tier to another in an application.

Separating Display and Modification Concerns

The differences in the needs of data display vs. data modification dictate that they be approached differently when developing software. In a modern n-Tier application, the same data will often be transferred across a wire several times. Database to Business Layer, Business Layer to Client, Service to Service, etc. Transferring a collection of rich object graphs when only pieces of information from that graph need to be displayed is wasteful of resources across all the tiers of an application. Transferring a rich object graph to a view for editing that information is essential, and therefor not necessarily wasteful, since all the details of the information being edited are required.

Older software development paradigms, such as ADO.NET with Data Sets, natively support this separation of concerns. A simple DataTable may be retrieved with exactly the information that needs to be displayed. A DataSet containing the full relational set of information required for editing may be retrieved for edit. A DataSet will also track changes and make bulk persistence of all changes simple when it is sent back to the business layer. However, DataTables and DataSets are weakly typed, simple structures that don’t fully represent the domain of an application.

Display vs. Modification w/ LINQ to SQL & Entity Framework

Modern software development paradigms involve rich domain models that accurately reflect a problem domain. Product objects represent products, Category objects represent categories, Categories contain collections of products, etc. Object graphs in a domain layer can be quite rich and complex. Things aren’t just sets of data, they are functional entities, replete behavior, continuity, integrity and relationships. The complexity of these rich object graphs has given rise to the use of O/R Mappers, which serve as intelligent data access layers capable of dynamically generating SQL statements and materializing object graphs for you, with minimal effort on the part of the developer.

LINQ to SQL is a basic, SQL Server only O/R mapper from Microsoft. While it does not provide super rich modeling capabilities, cross database support, or broad support for service-oriented applications, it does provide support for retrieving flat, non-structured data sets. L2S offers great support for “custom projections”, where specific pieces of information from various related entities in a domain model may be selected into an anonymous result set, or into a strongly type result set using a custom class.

Entity Framework is a rich, fully featured, cross-database O/R mapper from Microsoft with broad support for service-oriented applications. Entity Framework supports a wide range of entity to table mappings, giving it a degree of mapping flexibility that L2S just can’t approach. Unlike L2S, however, Entity Framework does not efficiently support custom projections. The current SQL statement generation pipeline makes the assumption that you are always querying for full entities or graphs of entities. The SQL generated for custom projections by EF can be quite inefficient, and at times, it can be incorrect and cause massive amounts of data to be processed by the database engine.

Right Tool for the Job

If you are attempting to simplify your projects, reduce overhead, and improve efficiency for your applications, make sure you pick the right tool for the job. Use object graphs when they provide useful benefit, and use simple, flat result sets when you don’t need the full richness of an object graph. Find and use tools that will support these patterns in an efficient way. LINQ to SQL may not offer rich mapping like Entity Framework, but it does support flexible querying and allows developers to retrieve the information they need with minimal resources. Methodologies like DDD encapsulate and isolate data access from the rest of an application through the use of Repositories. Some of the additional benefits of EF could be spoofed internally in Repository classes, allowing L2S to be used in the interim until EF matures more and offers better support for data display concerns.

Domain Driven Design

2008-09-22T22:25:00.001-06:00

Not too long ago, I encountered a failure in an architecture I had designed, and was trying to implement. The general design of the architecture was fairly good. It followed strict coding guidelines, implemented standard patterns, introduced some new patterns to solve common business problems, and, due to the very patterned nature of all the classes, was very code-generation friendly. This architecture allowed my team and I to move beyond the existing code base of random, chaotic code that solved individual, daily technical problems (or, as it more often was, provided a workaround instead of actually solving the problem). We established good coding practices, became object oriented, and came to a full understanding of the applications we were developing.

Due to the success of our architecture, we were finally able to move past mundane bug fixes that continually plagued us. We were now able to write new code to implement new features. Everything was great…until the database schema changed. This was where the weakness of our architecture became apparent. In the process of trying to make our application more structured, layered, and object oriented, I had failed to account for the need for fully independent adaptability in both our business objects and database schema. Our business objects were not persistence-ignorant…rather, in my efforts to build a system that would perform very well, our business objects became tightly bound to their knowledge of the database schema. Suddenly the nice, clean, simple world I had created exploded, and the daily grind became a process of updating our database to support a new feature, then the grueling task of updating all the dependant code to match. We had code generation in place, via CodeSmith, but that only alleviated some of the pain (and also created some of its own). Ultimately, the only conclusion I could come to was that I had failed. I achieved a structured, object oriented architecture, but still failed to provide a platform upon which we could solve business problems.

I spent the next several months trying to figure out ways to solve the problem, during which time we upgraded to Visual Studio 2008. I immediately fell in love with LINQ, and dove into planning for a new architecture built around this wonderful new technology. It was during my research on LINQ to SQL, and early information about Entity Framework, that I came across the various discussions on the concept of Persistence Ignorance, and the need for it to be supported in any decent O/R mapper. My explorations of PI lead to explorations of modern architectures, which eventually lead to my discovery of a most wonderful book: Domain-Driven Design: Tackling Complexity in the Heart of Software, by Eric Evans. I can say nothing less than that this book has completely changed the way I look at software development. In my attempts to refactor our applications and processes to follow the guidelines of DDD, I have learned more about both the business of developing software, and the business of the company I work for, than any other time in my career.

There is a lot of buzz these days about the various software development methodologies or pseudo-methodologies, and how they can help speed up software development and improve the quality of code. You always hear about testability, adaptability, quality improvement, distribution, all those common-sense things that can help solve the technical problems of a technical profession. The thing that intrigues me about DDD is that the emphasis is not so much on solving technical problems encountered by developers (however it does address them), as it is on connecting with business (domain) experts, learning how to communicate with those domain experts, and collaborating with them on the construction of a cohesive model and common language that reflects the problem domain and the business processes involved. Because that’s ultimately what we as developers are all about…solving business problems.

The bulk of my efforts recently have been put into learning Entity Framework, and applying that new-found knowledge towards creating a new architecture for our projects. The goals this time are focused less on solving technical problems, and more on solving business problems. In addition to providing a framework of collaboration between developers and domain experts in the form of domain modeling, DDD provides a core set of patterns and guidelines to help implement that model in code, and write software that solves the problems at hand. This new approach to software development has been quite refreshing, and when DDD practices are applied, I have found it easier to write simple, concise code that directly solves the problem at hand without any extraneous fluff. The software patterns advocated in DDD: Tackling Complexity have also helped me to develop code that is unit-test friendly, even when using LINQ to SQL or LINQ to Entities.

For anyone who is interested in simplifying their life as a developer, and getting to the heart of the problem, I highly recommend Domain Driven Design. It is a refreshing approach to software architecture and design, and offers some great solutions to common problems encountered in any software project. DDD isn’t bound to any specific software development methodology, either, so regardless of whether your Agile, XP, RUP, or a home-grown methodology, DDD still has a lot to offer.

Alongside my discussions on Entity Framework and other Microsoft technologies, I hope to document some of my experiences with DDD and its use with those technologies.

http://www.domaindrivendesign.org/index.htm

Having navigation properties and keeping your basic properties too!

2008-09-16T22:45:00.001-06:00

When LINQ to SQL first hit the scene, software development on the Microsoft platform changed forever. We all finally had a nice, albeit simple, O/R mapper that allowed us to flexibly query an object model in a wide variety of ways. Then Entity Framework appeared on the scene, promising better mapping capabilities, a better designer, and a much richer framework for O/R mapping overall than L2S would ever provide. Well, so we hoped. EF isn’t without its quirks and limitations.

One of the limitations of Entity Framework is its inability to have a single schema-level property mapped to more than one conceptual-level property in the same entity. In L2S, you could easily have had a basic property for a foreign key, while also having a reference property (or navigation property in EF-speak). This allowed a very wide variety of queries, and made it easy to update single entities and submit those changes to the database without needing related entities to be loaded as well. For the most part, EF still supports all that, but in a much more round-about way, involving the creation EntityKey instances and the like.

Currently, if you wish to set a foreign key value on an entity, you need to do something akin to the following:

      1: using (ObjectContext db = new ObjectContext())       2: {       3:     EntityWithFK entity = db.EntitiesWithFK.First();       4:         5:     // Create an entity key to represent the foreign key       6:     EntityKey key = new EntityKey("Entities.Foreign", "KeyColumn", 1);       7:         8:     // Change the foreign key without loading the associated object       9:     entity.ForeignReference.EntityKey = key;      10:           11:     db.SaveChanges();      12: } 

Simple, or so it seems. If you are working with an entity that already had a related entity set for that key, then you would also need to clear any existing entity before setting the new key. You can imagine what happens when you have a composite foreign key to an entity with a composite primary key. Wouldn’t it be nice to just set the key properties directly, like you used to be able to in L2S? Well, its not too difficult with partial classes and a little bit of encapsulation. A single-column key is easy:

       1: public int ForeignKey       2: {       3:     get       4:     {       5:         // Get the first value of the entity key values, its a single-column key       6:         EntityKey key = ForeignReference.EntityKey;       7:         int keyValue = (int)key.EntityKeyValues[0].Value;       8:         return keyValue;       9:     }      10:     set      11:     {      12:         // Clear the reference of any existing value before changing the key      13:         if (ForeignReference.Value != null)      14:         {      15:             ForeignReference.Value = null;      16:         }      17:        18:         // Create new entity key and replace the reference one      19:         EntityKey key = new EntityKey("Entities.Foreign", "Key", value);      20:         ForeignReference.EntityKey = key;      21:     }      22: }  

If you have a composite key, things are just a tiny bit trickier. You can’t create an entity key in pieces, you have to create it all at once. Just make some read-only properties to get the individual key values, and create a method to replace the whole key at once:

       1: public int ForeignKeyA       2: {      3:     get       4:     {       5:         EntityKey key = ForeignReference.EntityKey;       6:         int keyValue = (int)key.EntityKeyValues[0].Value;       7:         return keyValue;       8:     }       9: }      10:        11: public char ForeignKeyB      12: {      13:     get      14:     {      15:         EntityKey key = ForeignReference.EntityKey;      16:         char keyValue = (char)key.EntityKeyValues[1].Value;      17:         return keyValue;      18:     }      19: }      20:        21: public EntityKey SetForeignKey(int keyA, char keyB)     22: {      23:     // Clear any currently referenced entity for the foreign key      24:     if (ForeignReference.Value != null)      25:     {      26:         ForeignReference.Value = null;      27:     }      28:        29:     // Create a new entity key for a composite key      30:     EntityKey key = new EntityKey("Entities.Foreign",      31:         new[] {      32:             new EntityKeyMember("KeyA", keyA),      33:             new EntityKeyMember("KeyB", keyB)      34:     });      35:        36:     ForeignReference.EntityKey = key;      37:        38:     // Return the key so other code may use it      39:     return key;      40: }  

There you go, a nice, clean, simple, encapsulated way to manage your foreign keys when you don’t have an instance of the entity for the other end on hand. (All we need now is for it to be automatically generated…perhaps in another article). The great thing about Microsoft frameworks…if they didn’t get it perfect themselves, at least we have the flexibility to perfect it ourselves.

Code Bits: Scoped ObjectContexts

2008-09-12T21:12:00.001-06:00

Recently, I have noted a question arise again and again regarding the EF ObjectContext: Out-of-scope contexts, where a context is created in a method to retrieve entities and return them, only to have further operations with those entities, such as adding an associated object, fail. The most obvious solution is to pass the ObjectContext into the function returning the entities as a parameter…but that can quickly snowball, requiring many other functions be modified to take that context as well.

My solution to this problem was to create the ObjectSpace<T> class. This class is a relatively simple wrapper around ObjectContext, and allows a context to be shared across function calls much in the same way a TransactionScope can be shared. I follow the same general “scope” idea set forth in another article on the ImpersonationScope. The general idea is to keep track of “previous” object spaces, and “inherit” the ObjectContext from the ObjectSpace on the top of the stack. Ultimately, this allows something like the following:

      1: RootEntity InnerFunction()       2: {       3:     using (ObjectSpace<EFContext> space = new ObjectSpace<EFContext>())       4:     {       5:         RootEntity entity = space.Context.RootEntities.First();       6:         return entity;       7:     }       8: }       9:        10: void OuterFunction()      11: {      12:     using (ObjectSpace<EFContext> space = new ObjectSpace<EFContext>())      13:     {      14:         RootEntity entity = InnerFunction();      15:         entity.Child = new ChildEntity      16:         {      17:             ID = 1      18:         };      19:        20:         space.Context.SaveChanges();      21:     }      22: }  

The above example would normally fail in OuterFunction when the Child property was set. The ObjectSpace<T> class allows InnerFunction to inherit the ObjectContext created originally in OuterFunction, so all entity changes are tracked by a single context, not multiple contexts. Since the context is not being passed in as a parameter, one need not be created in OuterFunction if only a retrieval is needed. In addition, if InnerFunction needs to call into other functions to retrieve other entities, the context does not need to be explicitly passed to them either, etc.

With the full version, additional functionality is provided allowing some control over when changes are persisted to the data store when a child instance requests a save. The full source code as well as a .dll containing ObjectSpace<T> and ImpersonationScope are available on my SkyDrive’s Code Bits folder. You can download the source code directly here:

Please let me know how this works for you, or if you have any problems/find any bugs. I originally implemented this concept in a class called DataScope for LINQ to SQL, and have used that for many months. ObjectSpace is a bit newer, and somewhat more complex, and is not tested as well.

NOTE: No warranties or guarantees, express or implied, are given to anyone using code provided on the Architectural Musings blog, downloaded from Jon Rista’s SkyDrive at live.com, or otherwise acquired.

Store-Generated Columns in EF

2008-09-01T21:18:00.001-06:00

Today, as I continued my great journey through the wonderfully confusing new world that is Entity Framework, I encountered an interesting scenario. Most of the tables in the model I am currently working with have three common columns: DateCreated, DateModified, and ModifiedBy. These three columns are generally just internal tracking, with the DateCreated being automatically generated by SQL Server with a call to GetDate(). I ran into some trouble when inserting records into the database for these tables, however, as EF was requiring me to set a value to the DateCreated property before I could call SaveChanges().

As it turns out, the .edmx generator does not mark these columns in the CSDL as being store generated. Property definitions in a CSDL EntityType have a StoreGeneratedPattern attribute that defines how the data store will generate and insert or update values for such properties:

       1: public enum StoreGeneratedPattern       2: {       3:     None,       4:     Identity,       5:     Computed       6: }

My first choice was to use Computed, since Identity is most commonly meant to refer to sequentially increasing values in a column like a primary key. As it turns out, the terms are a bit misleading. A Computed pattern means the value is updated by the data store on both inserts and updates, which changes how EF performs updates as it needs to retrieve the regenerated values after an update is complete. The Identity pattern, on the other hand, just means that the value is generated once on insert, and not on update. This differs a bit from IDENTITY columns in SQL Server 2005, and can be misleading to anyone trying to solve persistence issues on columns that have non-identity generated values (i.e., GetDate()).

O/R Mapping with Entity Framework: Part 2

2008-08-30T01:22:00.001-06:00

The ADO.NET Entity Framework is a new data access platform that arrived with .NET 3.5 SP1. Building upon the foundation provided by ADO.NET, Entity Framework moves beyond simple row-column access to data (i.e. IDataReader, DataSet), and offers full-featured O/R mapping…materializing (or hydrating, as some say) data into object graphs. O/R mapping is not a new concept, and numerous existing solutions exist for the .NET platform today. The most well-known of these is probably nHibernate, an open-source .NET port of the popular Hibernate O/RM for Java.

Benefits of Entity Framework

Given that O/RM is not new, and that many O/RM solutions exist, why use Entity Framework? EF brings several advantages to the table that other OR/M’s don’t (yet) or can’t provide. Obviously for one, its part of the .NET framework now, and as such is standard, readily available, fully integrated, highly extendable, and all the other wonderful things you get from a Microsoft solution. Secondly, EF has a complete and highly optimized LINQ solution right out of the box. LINQ is a powerful new feature of C# and VB.NET that brings a native, strongly typed querying language to compiled code. (Good by, SQL!!) Other benefits include an integrated visual designer for VS2008 and rapid model generation/update capabilities.

Drawbacks of Entity Framework

On the flip side, despite what it has to offer, Entity Framework does have a few drawbacks. The most notable drawback is lack of maturity as far as O/RM solutions go. In its current incarnation, EF offers limited support for mapping scenarios. Mapping the differences between a relational data store and programmatic object graphs is the primary job of an O/RM. Other O/RM packages currently offer more complete mapping capabilities (LLBLGen Pro in particular offers some extensive mapping and templating tools for .NET). The visual designer for EF is also fairly limiting, supporting fewer capabilities than the broader set supported by EDM (Entity Data Model) itself when working with the XML mapping specifications directly. Over time the lack of maturity of EF will fade away as Microsoft’s broader vision forms and EF’s capabilities are expanded.

Another drawback of EF v1.0 is its current reliance on a base class for its generated entities. The inclusion of a base class can complicate the use of business entities in practical N-Tier or SOA environments, cause unwanted extraneous code to execute, etc. POCO, or Plain Old CLR Objects, promotes a paradigm where all business objects are simple classes, deriving from no common base class, with only logical inheritance chains where they belong (i.e. Vehicle <- Car <- Sedan) . POCO offers a much cleaner separation of the business layer from the data layer, while at the same time making it easier to serialize light-weight object graphs back and forth between a service and a client (no extraneous fluff like change tracking getting in the way).

[NOTE: Entity Framework v1 currently supports IPOCO, or Interface-based POCO. This allows classes to be used with EF without requiring a base class, but does require several interfaces to be implemented on each class. A full separation of the business layer from the data storage layer can not be achieved, however a more light-weight use of EF is possible.]

Tying in tightly with POCO is Persistence Ignorance (PI). In Domain Driven Design, a clean separation of business concerns from other concerns (such as data storage) is important. When your business objects must know about the persistence layer to be persisted, that clean separation is shattered with extra code and computation. Existing O/RM solutions like nHibernate offer full persistence ignorance and allow objects to be used without any concern about how or where the data they hold is stored or later loaded.

[NOTE: Entity Framework v2 is currently slated to support snapshot-base change tracking, Persistence Ignorance, and POCO support. Existing persistence mechanisms will continue to be supported.]

Practical O/R Mapping with Entity Framework

Given the drawbacks to using Entity Framework v1, can it’s benefits make it practical for use in modern software development scenarios? I believe that Entity Framework v1 can indeed provide solutions. Despite its lack of support for some important modern software design patterns, EF can still fill the role of an O/RM, which is the primary need regardless of the programming methodology you choose to use. Using EF is largely a process of overcoming the limitations of visual tools, working within the existing rules, and learning the full capabilities offered at the XML level of EDM (which currently offer more than the visual tools support).

In the next installment of this series, I’ll introduce a very simple problem domain, and create the conceptual model that will drive the C# classes and database schema that will meet the needs of that domain. The ultimate goal is to map between the required .NET classes and a SQL database using EDM, keeping as close as possible to the conceptual model.

O/R Mapping with Entity Framework: Part 1

2008-08-25T22:00:00.000-06:00

Over the last several months, I have been playing with ADO.NET Entity Framework, starting with the last 2007 CTP, moving through SP1 Beta 1, and now finally with the v1 RTM. Entity Framework is an incredible addition to the .NET developer’s toolbox, no doubt about it. It expands upon LINQ to SQL in a few critical areas that were real failing points before…namely in the areas of model creation and management, N-Tier/SOA support, serialization, and practical O/R Mapping. There is an incredible amount of potential behind Entity Framework, and not just from a pure programming aspect. Entity Framework will ultimately bring a rich, queryable object space to reporting, business intelligence, and software development, unifying our data retrieval operations and promoting them up from the data schema level to the business conceptual level.

Entity Framework v1 is not without it’s shortcomings, however. In its current incarnation, it provides limited O/R mapping capabilities (albeit better than L2S), and has a frustrating change-tracking mechanism. That is nothing to say about the common issues so thoroughly reiterated by the community, such as missing POCO support. Using EF today is a difficult task, and many issues need to be overcome. Many of these issues are simply due to an immature understanding of EF’s capabilities by the community at large. Some arise from poor integration with other technologies, such as WCF, or lack of interoperable standards for needed functionality (object graph serialization). Some are due to hard-coded limitations that, for the time being anyway, we have to live with. Given that the next version of EF is a good 6 months to a year away at best, now is the time to start finding solutions, or workarounds, to the limitations and restrictions imposed by EF v1.0.

O/R Mapping with Entity Framework

Since shortly before the release of .NET 3.5 SP1, I have been trying to build a relatively simple EDM model of a conceptual domain that is not a 1-1 entity-to-table map of the database. The EDM designer has been less than forgiving of mistakes, and down right refuses to allow much of the functionality I would have expected in an O/RM design tool. This largely stems from the lack of support for many of the features of EDM itself (the XML schema/conceptual/mapping language of Entity Framework) in the visual model designer for VS2008 SP1. I spent the better part of 2 weeks figuring out how to accomplish the simple conceptual model I needed, and in the end had to settle for a happy medium between my ideal model and the direct 1-1 entity-to-table model generated for me. Most of the work was done by manually editing the generated XML until I figured out how it all worked at a low level.

Beyond all the general talk in the community about the need for POCO, snapshot-based change tracking, proper object graph serialization, etc., the core critical role EF plays in any project is as an O/RM, or Object/Relational Mapper. I won’t go into a detailed explanation of what O/RM is, however to put it simply…O/R mapping is the process of transforming information from the hierarchical object graphs we use as programmers onto the relational table structures we use to store information in. O/R mapping solves what we call the impedance missmatch, fundamental differences between how we use objects and how we store data. Creating a proper, domain-driven conceptual model for your project, and using EF map between the conceptual model and the database, is definitely possible with v1. It’s just a bit difficult and requires some knowledge about the differences between what EDM (Entity Data Model) supports at the XML level, and what the designer doesn’t support.

In future installments of this series of articles, I’ll cover how to create a conceptual model that fits most of the needs of a simple problem domain, and achieve one of the core requirements of DDD (Domain Driven Design): isolation of the domain model from the database schema.

Projects: Visual Studio Line Counter

2008-08-23T14:25:00.001-06:00

Back in 2006 I wrote an article on CodeProject explaining how to write an add-in for Visual Studio 2005. The subject of my add-in was counting lines of source code. The idea came from PLC, Project Line Counter, from WndTabs.com, and I enhanced it to support some of the features I personally wanted. The article and the add-in have become very popular, however it does not work in Visual Studio 2008.

I have begun working on this project again, however there seem to be some issues getting the addin to work with Visual Studio 2008 in its current form. There have also been requests to support 64-bit editions of Visual Studio, non-english installations, single-package deployment for both VS2005 and VS2008, etc. In the long run, I will probably have to rewrite the tool from scratch to support the needs of the community.

I’m starting a Projects column here on my block to track progress on the various little tools and utilities I have started and shared over the years. Any progress and updates I make on these tools (time permitting, as I still have a demanding day job) will be posted here.

Code Bits: ImpersonationScope

2008-08-22T17:00:00.000-06:00

Now that I have a blog, I have a nice avenue for providing useful tidbits of code to the .NET development community. There are always times when you discover or create some clever solution to an annoying little problem and stuff the solution away in your personal code library. I’ve learned many a trick from the thousands of others who have posted their useful little code bits on sites like The Code Project or on their blogs.

Time to introduce “Code Bits”, a column on my blog where I’ll post those useful little tidbits that solved some little problem somewhere in my daily work. For the first installment, I’d like to introduce the ImpersonationScope. This useful little utility class allows quick and easy impersonation of a Windows user in your code, allowing all operations performed to be done under a different security principal than for the currently logged in user. This is similar to ASP.NET impersonation, only it can be stacked (you can use it multiple times to repeatedly change the impersonated user in a call chain), and is not restricted to the ASP.NET environment.

Impersonating a windows user is possible with the System.Security.Principal.WindowsImpersonationContext type, but it requires using some imported functions from advapi32.dll and kernel32.dll, which can clutter up your otherwise clean code:

       1: #region Imports       2: /// <summary>       3: /// Enumeration of valid logon types.       4: /// </summary>       5: enum LogonTypes : uint       6: {       7:     Interactive = 2,       8:     Network = 3,       9:     Batch = 4,      10:     Service = 5,      11:     Unlock = 7,      12:     NetworkCleartext = 8,      13:     NewCredentials = 9      14: }      15:        16: /// <summary>      17: /// Enumeration of Windows NT logon providers.      18: /// </summary>      19: enum LogonProviders : uint      20: {      21:     Default = 0,      22:     WinNT35,      23:     WinNT40,      24:     WinNT50      25: }      26:        27: /// <summary>      28: /// Logs on the specified windows user with the given credentials.      29: /// </summary>      30: /// <param name="principal">The username to log on with.</param>      31: /// <param name="authority">The domain for the user.</param>      32: /// <param name="password">The password for the user.</param>      33: /// <param name="logonType">The LogonType to use.</param>      34: /// <param name="logonProvider">The LogonProvider to use.</param>      35: /// <param name="token">The security token if logon is successful.</param>      36: /// <returns>True if logon was successful, false otherwise.</returns>      37: [DllImport("advapi32.dll", SetLastError = true)]      38: static extern bool LogonUser(      39:     string principal,      40:     string authority,      41:     string password,      42:     LogonTypes logonType,      43:     LogonProviders logonProvider,      44:     out IntPtr token      45: );      46:        47: /// <summary>      48: /// Closes the specified windows handle.      49: /// </summary>      50: /// <param name="handle">The handle to close.</param>
      51: /// <returns>True if closure was successful, false otherwise.</returns>      52: [DllImport("kernel32.dll", SetLastError = true)]      53: static extern bool CloseHandle(IntPtr handle);      54: #endregion
  

The LogonUser method imported from advapi32.dll outputs a windows security token handle for a given set of credentials that is required when creating a .NET System.Security.Principal. WindowsIdentity. Once you have the WindowsIdentity, you can impersonate, allowing any further operations performed in the current thread to run with the new credentials. When your done, and no longer need your code to run under a different security context, simply call WindowsSecurityContext.Undo() to revert back to the current user’s context:

       1: IntPtr token = IntPtr.Zero;       2: bool success = LogonUser(       3:     "username",       4:     "DOMAIN",       5:     "password",       6:     LogonTypes.NewCredentials,       7:     LogonProviders.Default,       8:     out token       9: );      10:        11: if (!success)      12: {      13:     int ret = Marshal.GetLastWin32Error();      14:     Debug.WriteLine(      15:         "LogonUser call failed with error code : "      16:          + ret      17:     );      18:     throw new Win32Exception(ret);      19: }      20:        21: WindowsIdentity identity = new WindowsIdentity(token);      22: WindowsImpersonationContext context = m_identity.Impersonate();      23: CloseHandle(token);      24:        25: // Do stuff under impersonated context      26:        27: context.Undo();  

The ImpersonationScope class is a security utility that wraps up all the code listed above, and effectively reduces its complexity down to a 1-liner with a using block. Create the ImpersonationScope in a using statement, and when the using block ends, so does the impersonation:

       1: using (ImpersonationScope scope = new ImpersonationScope("username", "DOMAIN", "password"))       2: {       3:   // Do stuff under new security context here       4: }  

That’s all there is to it! Simple, clean, easy impersonation of alternate windows identities. In the last couple months I have run into two scenarios in my daily work where impersonation was necessary, and this little class is the result. You can download the source code here:

Finally Joining the Fray

2008-08-21T13:06:00.003-06:00

I've long been one of those generally silent readers of technical blogs. I love browsing around and absorbing the useful tidbits of information the great blogging community leaders are always tossing onto the net. There is so much great information, and I continually learn so much from those individuals who take the time to share.

I have decided its time to join in, and start providing some of my knowledge and musings to the world. Some of my existing outlets, like forums or my personal favorite site, CodeProject.com, have allowed me to help to a degree. However, I think a blog will give me more flexability in portraying my thoughts without them getting buried in a forum thread or requireing the kind of effort needed to create a good CodeProject article. So, here it is, my first blog.

In the comming weeks and months, I hope to start writing about some of the latest technologies from Microsoft, namely the ADO.NET Entity Framework, Windows Communication Foundation, and practical domain-driven, n-tier software development with these technologies (and of course the broader .NET platform). There is an incredible amount of potential behind these technologies, and combined with Microsofts software development tools, they are relatively easy to use at a basic level. There are some inherent limitations and restrictions in using them together in their current forms, however, and successfully using them practical real-life scenarios can be a complicated and difficult task.

I hope this blog will help me to overcome these limitations through discussion with the community, and provide useful answers to problems that are commonly encountered using the various new .NET technologies we've all been so excited about over the last year.

Until my next post...