Vishful thinking…

POCO pollution in ORMs

Posted in Uncategorized by viswaug on February 12, 2009

One of the improvements that have been made in the ORM universe is the movement towards using POCOs (Plain Old CLR Objects) instead of bloated types which pack different methods and extraneous properties that don’t really belong there. What does that really mean? Most of the ORM frameworks used to force your entity classes to inherit from a bloated base class that provided a lot of functionality that life a lot easier. So, your entity classes where not really a POCO. Entity classes that are POCOs should only contain properties and fields that they need persisted and nothing else. Using POCOs helps you achieve a clean separation of concerns that helps keep your design clean and flexible. One of the problems that you will quickly run into when using entity classes that inherit from bloated base classes is with serialization both to XML and JSON.

NHibernate is one ORM that I have used and like. The framework lets us keep the entity classes class by using POCOs and letting us store all other information like property to table column mapping etc in XML files. The framework is also committed to not polluting the POCOs. When using NHibernate, you say “Session.Save(customerEntity);” and not “customerEntity.Save();”. Meaning, the customer entity does know how to save itself but instead the database session is the one that knows how to save a customer entity. And thus the customer entity can be stored in any storage mechanism required (as XML to files etc) and not just a database.

I have been using LLBLGen (for an Oracle back-end) lately and even though it is very well designed for most use cases. But they definitely are not committed to keeping POCOs just POCOs. The definitely use heavy use of base classes. But I do have to admit that the functionality that the base classes pack with them really do save time during development for just purely database persistence.

The Enterprise Validation Application Block (VAB) also allows you to decorate your entity classes with Validation attribute decorators that really tie in domain logic into your POCOs. This validation logic can really be removed from there and provided in code but it does involve work. And as the developers, we have to make the decision as to whether that extra effort is worth it given the requirements for your projects.

Even the Entity framework team from Microsoft have realized the advantages of not polluting the POCOs. The framework started with using bloated entity classes and have slowly started their migration to using POCOs. Even thought that migration is not complete, they have made efforts towards it and have currently adopted using the Three Amigos of the non-existent IPOCO interface (which by itself defeats the cause of moving to POCOs). The framework has these interfaces in place for POCO wannabes…

So, paying more attention when selecting your ORM and to whether you are currently using pure POCOs (not pretenders) or bloated types in your application framework should help you down the lane when are trying to persist your types to someplace other than the database or trying to JSON serialize them.

ArcToSQL2008 – An ArcCatalog Command to export FeatureClasses to MS SQL SERVER 2008

Posted in ArcGIS, ESRI, GIS, SQL Server 2008, Utilities by viswaug on February 12, 2009

I had written this tool 3-4 months ago and it had been sitting on my machine waiting to be wrapped with an installer project. I finally got around to building a setup and deployment project for it and it is ready to distribute. The tool can be downloaded below


Once installed, you should be able to open the “Tools -> Customize” dialog in ArcCatalog


Under the “GeoSpatial.NET” Categories, the “ArcToSQL2008” command should be available. Drag the command to any of the toolbars.


Select the FeatureClass you want to export to the SQL Server 2008 database and click the “ArcToSQL2008” button on the toolbar. The dialog below should pop-up. Enter the name of the SQL Server 2008 database server and click connect. The Database drop-down will get populated with all available databases on the server. Select a database from the list and enter the name of the table that you want the FeatureClass exported to. Click OK. The FeatureClass will get exported and a message box should pop-up when the import is completed.


Some highlights of the tool:

  • Exports FeatureClasses in a Projected Co-ordinate System as SQLGeometry in SQL 2008.
  • Exports FeatureClasses in a Geographic Co-ordinate System as SQLGeography in SQL 2008.
  • Any errors that occur during the export are logged in a log file found under in the install directory.
  • The tool is built using a broader GIS framework that should enable developers to customize the export process to their liking. I still have a little bit of house cleaning on the code for the broader GIS framework. I will post when it is all done. Hopefully that will be real soon. Contact me if you want to look at it sooner…

Things left to do:

  • Better UI showing the progress of the export operation.
  • More flexibility to the export operation by allowing the user to select the fields to be exported.
  • The export operation can be made faster by using the geometry builder classes to construct the SQLGeometry and SQLGeography objects. I took the shortcut for now and just parsed out the geometries from WKT strings.

Please let me know if you find any bugs in the tool using the “contact me” link on the right pane of this blog.