in

ASP.NET Weblogs

Yves Reynhout's Blog

The seagile man

  • DLinq - First Impression

    I thought I'd just have my say about this as these gentlemen already have [ PeeWeeWilson & Fouma ]. After having read the overview paper (rather diagonal I might add) I can't help but notice the three-way mapping is gone (domain schema <-> mapping schema <-> relational schema), which I find a pitty. From the simplicity point of view I can fully understand why, but believe me when I say that flexibility is sacrificed.
    Recently Steve Eichert mentioned using DataContract     as a way to describe what is persistable and what is not. An interesting idea, but there are too many references to the web service world (Namespace, MustUnderstand, ...). Secondly, if I'd like to expose the class/message using [DataContract] via a web service I wouldn't feel very comfortable with "what is persistable" and "what is part of the message" being the same. Creating a new set of attributes [PersistenceContract], [PersistenceMember(Name=...)] and [PersistenceMemberReference(Name=...)], [PersistenceConstructor] sounds more appealing to me. They could form the domain/persistence schema, which could in turn be consumed by the mapping schema or code which defines the mapping/transformation.
    Unlike Paul and Frans, I don't advocate against using attributes. What I do advocate against is the fact that relational concepts such as table, column, native or abstract column types, primary or foreign key and relationship show up in my domain model, and this for the very same reasons as Paul & Frans do (call it one thing in SqlServer, call it another in Oracle; inject some kind of custom transformation in the mapping because there is a mismatch between the CLR type and the native db type). Unfortunately this is exactly what DLinq does. Marketing-wise this could be interpreted as "Let's sell more SQL servers". Opening things up would only allow you to switch to Oracle more easily. Wether that was the reasoning behind this all, I really don't know. Let's just hope that in the future DLinq will embrace flexibility and database independence.
    Resources on Linq
    Posted Sep 16 2005, 12:32 PM by yreynhout with 1 comment(s)
    Filed under: ,

  • Computing on demand

    An interface I find very useful lately is IComputeOnDemand (although it is highly debatable if it should be an interface at all):

    /// <summary>
    /// Behavior for things that can be computed on demand.
    /// </summary>
    public interface IComputeOnDemand {
      /// <summary>
      /// Gets a value indicating whether this instance is computed.
      /// </summary>
      /// <value>
      ///     <c>true</c> if this instance is computed; otherwise, <c>false</c>.
      /// </value>
      bool IsComputed { get; }

      /// <summary>
      /// Gets or sets the inner value.
      /// </summary>
      /// <value></value>
      object InnerValue { get; set; }
    }

    Classes often have properties that only need to be computed once. The most used approach to handle this is by introducing some variable (e.g. loaded, calculated) which indicates if some computation has taken place. An example:

    public class SomeClass {
      private bool loadedField1;
      private int field1;

      public int Field1 {
        get {
          if (!this.loadedField1){
            //Do some "heavy" computation here.
            this.field1 = resultOfComputation;
            this.loadedField1 = true;
          }
          return this.field1;
        }
      }
    }

    While this is fine for one field, consider this scenario for multiple fields in one class. Pretty soon the class gets cluttered with these "loaded" fields. But there's even bigger danger lurking: What if you bypass the property and start using the field without it being initialized? Will you ever know? Ofcourse you only get this within the class itself (I'm assuming you've banned the evil called public fields). Let's add a new exception:

    /// <summary>
    /// The exception that is thrown when something is not computed. 
    /// </summary>
    public class NotComputedException: ApplicationException {
      /// <summary>
      /// Creates a new <see cref="NotComputedException"/> instance.
      /// </summary>
      public NotComputedException(): base() {}
      /// <summary>
      /// Creates a new <see cref="NotComputedException"/> instance.
      /// </summary>
      /// <param name="message">Message.</param>
      public NotComputedException(string message): base(message) {}
      /// <summary>
      /// Creates a new <see cref="NotComputedException"/> instance.
      /// </summary>
      /// <param name="message">Message.</param>
      /// <param name="innerException">Inner exception.</param>
      public NotComputedException(string message, Exception innerException): base(message, innerException) {}
    }

    What's next? Well, time for some code smitherings: For each of your compute on demand data types, you generate a "typed" holder class. I took System.Boolean as an example (mind the "no boxing here"):

    /// <summary>
    /// Represents a placeholder for a <see cref="Boolean"/> value.
    /// </summary>
    public class BooleanHolder: IComputeOnDemand {
      /// <summary>
      /// Creates a new <see cref="BooleanHolder"/> instance.
      /// </summary>
      public BooleanHolder() {
      }

      /// <summary>
      /// Creates a new <see cref="BooleanHolder"/> instance.
      /// </summary>
      /// <param name="innerValue">Inner value.</param>
      public BooleanHolder(Boolean innerValue){
        this.InnerValue = innerValue;
      }

      /// <summary>
      /// Gets a value indicating whether this instance is computed.
      /// </summary>
      /// <value>
      ///     <c>true</c> if this instance is computed; otherwise, <c>false</c>.
      /// </value>
      public bool IsComputed {
        get {
          return this._computed;
        }
      }bool _computed = false;

      /// <summary>
      /// Gets or sets the inner value.
      /// </summary>
      /// <value></value>
      public Boolean InnerValue{
        get {
          if (!this.IsComputed) {
            throw new NotComputedException();
          }
          return this._innerValue;
        }
        set {
          this._innerValue = value;
          this.MarkAsComputed();
        }
      }Boolean _innerValue;

      /// <summary>
      /// Gets or sets the inner value.
      /// </summary>
      /// <value></value>
      object IComputeOnDemand.InnerValue {
        get {
          return this.InnerValue;
        }
        set {
          this.InnerValue = (Boolean)value;
        }
      }

      /// <summary>
      /// Marks as computed.
      /// </summary>
      /// <returns></returns>
      private void MarkAsComputed(){
        this._computed = true;
      }
    }

    Using this approach you get a less cluttered class and a nice exception when using a field that wasn't computed. As noted by John Ritsema, in Whidbey generics can be used to simplify things (see comment for how-to).

    public class SomeClass {
      private BooleanHolder field1;

      public bool Field1 {
        get {
          if(!field1.IsComputed){
            //Do some "heavy" computation here.
            this.field1.InnerValue = resultOfComputation;
          }
          return this.field1.InnerValue;
        }
      }
    }

    I tend to appreciate the small things in life...
    Posted Jun 02 2005, 08:22 PM by yreynhout with 2 comment(s)
    Filed under: ,

  • Patents: System.Data.Mapping to resurface?

    What have we here?
    Posted May 18 2005, 08:58 PM by yreynhout with 6 comment(s)
    Filed under: ,

  • Visiting SQL - Update

    It seems like I'm not the only one who has been playing with this idea: sqlom
    Posted Apr 24 2005, 08:45 PM by yreynhout with no comments
    Filed under: ,

  • Visiting SQL - Part 2

    In part 1 I explained how I got a "typed model" of a database schema for building SQL in code. By itself I found this useful, but I still hated the string concatenation involved (not to speak of the scattering of all this string manipulation). So I came up with the idea to build a hand-made object model for all SQL query related objects. This model would allow me to build SQL statements in a typed and database-agnostic fashion, integrating nicely with my typed database schema model. To give you a rough idea I included some schematics:
    - The core interfaces -

    - The core classes (and some derived ones to give you an idea) -

    The main interfaces of interest are ISqlSerializable (a.k.a. IVisitable with the accept method replaced with the more appropriate WriteSql) and ISqlWriter (a.k.a. the Visitor). Basically, I've taken the visitor pattern and applied it to writing SQL, allowing for extensibility (    for each of the SQL dialects out there) and refraining developers (in theory) from polluting the code with string concatenated SQL. The not so apparent added value is the amount of reuse one can achieve with this type of model (from caching to creating dynamic views).
    The only drawback (maybe there are more, but this is the major one) to using an object model is that your SQL becomes very much unreadable as complexity grows. Then again, this may be a sign that you're not doing enough in your domain model or (e.g. for performance, security reasons) it might be wise to push this logic into a stored procedure. But even this can be solved, by simply modelling each query statement as a class, which can be easily serialized into SQL to see if you get the desired SQL statement (the truly brave might even parse a SQL string and reverse engineer it into the object model).
    I think there's enough food for thought in here. Sorry if I haven't gone into too much detail, but a high-level overview is what I had in mind. Feel free to inquire for more.
    Posted Apr 12 2005, 11:02 PM by yreynhout with 7 comment(s)
    Filed under: ,

  • Visiting SQL - Part 1

    Apparently, after some months of intensive work, I'm dieing to share (and reflect on) some of the things I've worked on.

    Although "pluggable database backends" and "SQL abstraction" were not directly goals of the project (regular OLTP app), I kind of stumbled on them by accident (just don't call me nuts yet). First off, a lot has already been written about "pluggable database backends", achieved using the IDbXYZ and IDataZYX interfaces which any decent .NET data provider implements, so I'm not gonna talk about that.
    At work, I tend to use a lot of dynamic SQL because I don't want too much of my business logic "locked" in stored procedures. The whole dynamic SQL versus stored procedures topic is not something I want to delve in now, so we're not gonna talk about that either. Dynamic SQL built in code suffers the problem that as the database schema changes, the "SQL building code" should change along with it. So how do you know which SQL building code is affected by changes in the database schema? If the SQL was somehow typed, the compiler would tell you. Making the SQL typed would mean that there should be some object model in place that, for starters, allows you to represent the database objects (think views, tables, columns, ...).
    Datasets, and in particular the typed flavor, come to mind. But they're a little bloated just to represent a schema     (and probably limited as to the types of database objects they can represent). I had a look at CodeSmith's SchemaExplorer (which BTW has a slick object model) but couldn't use it because it's use was primarly to discover the database schema at runtime. What I was looking for was a static definition of the database schema in C# code at design time (which I dubbed RelationalSchema). Although I'm not a big proponent of DIY, I really don't think I had much choice at the time. I borrowed some of SchemaExplorer's object model (in redux I might add), and made it xml serializable using one of those fine WSE interfaces, namely IXmlElement(who said you can't reuse wonderful material).
    Now that RelationalSchema was born, containing RelationalSchemaDatabase, RelationalSchemaTable, RelationalSchemaView and RelationSchemaColumn, I used CodeSmith to build a template that generates my xml representation of a relational schema. This way I could have an xml representation of any database schema I liked; just a matter of setting the proper connectionstring. Still, this was just a "generic" representation of a database schema. I still wouldn't detect database schema changes this way. Much like datasets definitions can be used to generate typed datasets, I needed a way to generate a typed relational schema. Again, CodeSmith to the rescue. I made a template which creates a typed object model based on the generic object model.
    If I was planning on using the "building SQL using strings" approach than my story would be done here. But it isn't...
    Posted Apr 09 2005, 12:31 AM by yreynhout with 2 comment(s)
    Filed under: , ,

  • The "facets-enabled" meta model

    During the course of my current project at work, I've been trying to come up with a way to describe the meta data of my domain model (which I dubbed the meta model).  Because I've taking a rather ObjectSpaces-like approach to object-relational mapping, the domain schema I created seemed like a good place to store the facets of my class members(fields and/or properties). Here's an example of what it looks like:
    <?xml version="1.0" encoding="UTF-8"?>
    <    DomainSchema AssemblyFullName="SomeProject, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" 
    xmlns="http://www.seagile.com/domainschema-1.0/" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation    ="http://www.seagile.com/domainschema-1.0/
    D:\WorkSpace\SomeProject\trunk\Schemas\DomainSchema.xsd"    >
        <Classes>
            <Class FullName="Seagile.SomeProject.SomeBaseClass" IdentityMember="ID">
                <Members>
                    <Member Name="ID" Field="_id" Type="System.Guid"/>
                </Members>
            </Class>
            <Class FullName="Seagile.SomeProject.SomeClass" BaseClass="Seagile.SomeProject.SomeBaseClass">
                <Members>
                    <Member Name="Name" Field="_name" Type="System.String">
                        <Facets>
                            <MinLength>1</MinLength>
                            <MaxLength>5</MaxLength>
                        </Facets>
                    </Member>
                    <Member Name="ExternalCode" Property="ExternalCode" Type="System.String"
                        Required="False" Default="MCQ000">
                        <Facets>
                            <FixedLength>6</FixedLength>
                            <Pattern>^MCQ\d{3}$</Pattern>
                        </Facets>
                    </Member>
                    <RelationshipMember Name="Category" Field="_category" RelationshipType="One" 
                        TargetClass="Seagile.SomeProject.SomeOtherClass"/>
                    <RelationshipMember Name="Materials" Field="_materials" RelationshipType="Many" 
                        TargetClass="Seagile.SomeProject.Material"/>
                </Members>
            </Class>
            <Class FullName="Seagile.SomeProject.Material" BaseClass="Seagile.SomeProject.SomeBaseClass">
                <Members>
                    <Member Name="Name" Field="_name" Type="System.String"/>
                    <Member Name="TotalParts" Field="_totalParts" Type="System.Int32">
                        <Facets>
                            <MinInclusive>2</MinInclusive>
                            <MaxExclusive>11</MaxExclusive>
                        </Facets>
                    </Member>
                    <Member Name="BarCode" Field="_barCode" Type="Seagile.SomeOtherProject.BarCode, SomeOtherProject" 
                        TypeConverter="Seagile.SomeOtherProject.Data.BarCodeConverter, SomeOtherProject.Data"/>
                </Members>
            </Class>
        </Classes>
    </DomainSchema>
    By itself the schema is worth nothing, but in conjunction with a mapping and relational schema it's "easy" for a generic mapping layer to interpret how to retrieve and store objects. Strictly speaking the mapping layer doesn't need the type information and facets. But their presence is very much appreciated by the domain, application and presentation layers. The presentation layer can use the information to constrain the input fields, and both the domain and application layer can feed these facet values to validators (LengthValidator, RegularExpressionValidator, Int32RangeValidator, ...).
    The xml representation is both a blessing and a curse. On one side, it's very easy to get up and running (using an xml schema to drive the intellisense and validation). It feels like a modelling tool if the schema is what you start out with. If the domain model is already in place it's a pesky task. Maintenance wise, however, it's a little devil. Having a validator to compare the declarative xml representation against an assembly is not a luxury. Keeping the code and xml in sync is asking for trouble. I think the best way to handle this is (a) to forget this whole idea, (b) have the xml representation generate the code or (c) have the code generate (attribute-based approach) the xml representation.
    But lets not forget the problem I'm trying to solve, namely preventing the scattering of the domain's meta data. Where do you store the fact a column is 5 long, how do you constrain the textbox representing that same conceptual value to only take 5 characters to have an overal nice end-user experience, and how about duplicating that value once more in the domain layer so that other "clients" of your code play by the rules? How do you deal with change and know where to look if 5 becomes 10?
    Posted Apr 08 2005, 08:04 PM by yreynhout with 1 comment(s)
    Filed under: , ,

  • Collection classes and behavior

    Lately I've come up with a technique to implement custom finders/queries/filters on my collection classes. Instead of implementing these finders/queries/filters directly in the collection class itself, which gets in the way of generating these types of classes anyway (for the record, I am aware of techniques like CodeSmith's merge regions), I defined a set of new behaviors:
    /// <summary>
    /// Behavior for things that can be evaluated.
    /// </summary>
    public interface IPredicate {
        /// <summary>
        /// Evaluates the specified obj.
        /// </summary>
        /// <param name="obj">Object to be evaluated.</param>
        /// <returns><c>true</c> if obj meets the predicate; otherwise <c>false</c>.</returns>
        bool Evaluate(object obj);
    }

    /// <summary>
    /// Behavior for collections from which items can be extracted using the given <see cref="IPredicate"/>.
    /// </summary>
    public interface IExtractable {
        /// <summary>
        /// Extracts the items from the collection given the specified predicate, leaving only the items that didn't meet the predicate.
        /// </summary>
        /// <param name="predicate">Predicate used to evaluate items against.</param>
         /// <returns>A collection of items that meet the given predicate.</returns>
        object Extract(IPredicate predicate);
    }

    /// <summary>
    /// Behavior for collections that can be filtered using a given <see cref="IPredicate"/>.
    /// </summary>
    public interface IFilterable {
        /// <summary>
        /// Filters the items in the collection given the specified predicate, effectively removing the items that match the predicate.
        /// </summary>
        /// <param name="predicate">Predicate used to evaluate items against.</param>
        void Filter(IPredicate predicate);
    }

    /// <summary>
    /// Behavior for collections from which items can be selected using the given <see cref="IPredicate"/>.
    /// </summary>
    public interface ISelectable {
        /// <summary>
        /// Selects the items in the collection given the specified predicate but leaves all items in the collection.
        /// </summary>
        /// <param name="predicate">Predicate used to evaluate items against.</param>
        /// <returns>A collection of items that meet the given predicate.</returns>
        object Select(IPredicate predicate);
    }
    Next I implemented the ISelectable, IExtractable, IFilterable in my collection class template (regardless of the templating mechanism you use). I even provided typed implementations of these methods (using explicit interface declaration).
    Foreach rule/condition I've come across in code, I've created a class implementing IPredicate. Feeding instances of my predicate classes to my collection classes allows me to perform either select, extract or filter operations on them. I've even taking this a step further and implemented a CompoundPredicate which basically is a collection of predicates and a predicate decision combinator (IPredicateDecisionCombinator). When a compound condition is passed to one of the select/extract/filter methods, multiple conditions are evaluated at once and the way the result of these evaluations are combined is the concern of the predicate decision combinator (so you can vary from the simple boolean and/or).
    There's some room for improvement, namely the Select and Extract could return ICollection or IList instead of object, but that's a matter of taste to me.
    The beauty of this solution is that the condition (predicate) is totally separate from the function     (extracting, filtering, selecting) I want to perform on the collection. Conceptually it is quite similar to Predicate<T> in .NET 2.0 or to IComparer and the Sort method in .NET 1.1 and to some extent to closures. Ofcourse in 1.1 it requires a little more work on your behalf, namely passing around contextual data via the constructor of the predicate whereas in 2.0 anonymous methods will do most of the lifting for you.
    Posted Apr 05 2005, 12:03 AM by yreynhout with 6 comment(s)
    Filed under: ,

  • SCC in Microsoft Visual Studio.NET 2002/2003: The good, the bad and the ugly

    GrantRi inquires about what type of SCC the hobbyist programmer uses. I was going to write a comment, but decided to rant about what has been annoying me with SCC in VS.NET 2K2/3.

    There are several reasons not to use the standard scc integration. For one, all this source control information is persisted inside the solution and/or project files. If you have ever tried to branch a solution, you will know what I mean. If you open the solution, you will notice that it is "bound" to the source control location it was originally branched from. To "bind" to the new location, you can use the "Change Source Control" functionality of VS.NET. In some cases you may want to get rid of this source control information. In that case you have to use the "unbind" functionality in VS.NET or alternatively alter the solution and/or project files by stripping the source control information. Secondly, the solution load time is increased if you use the SCC integration. Thirdly, if you use web projects and want to use your main development and branch versions concurrently, you're in for a big mess (although this statement also applies to other source control systems).
    The only positive thing about the source control integration is that using "Open from Source Control" a solution is "gotten" automagically (provided you accept that web projects are "gotten" to your local wwwroot ).

    For those who want to use the standard SCC integration in VS.NET with other sourcecontrol systems, you can use:
    Working with CVS:     http://www.pushok.com/soft_cvs.php
     Working with SVN: http://www.pushok.com/soft_svn.php

    Personally, I'm leaning towards Subversion(Server), TortoiseSVN(Client) and ANKH(IDE Integration).
    Posted Oct 06 2004, 09:45 PM by yreynhout with 5 comment(s)
    Filed under:

  • WSE 2.0 Extensibility: From spec to code

    I've started work on a WS-ReliableMessaging implementation over at Plumbwork.Orange. Although I haven't made any serious advances (usability wise), it already shows that WSE 2.0 extensibility model is awesome! If you plan on writing an implementation of a spec yourself on top of WSE 2.0, dig in using Reflector or fetch a fresh copy of the Plumbwork.Orange source.

    So, how's the code organized? You have a WS<spec>.cs containing all the string identifiers (namespace, actions, element names and attribute names) relating to the spec. This class has a real "add code as we go" feeling to it. Next up are the elements and their associated attributes described in the spec. Basically you need to provide an object model, and write the serialization & deserialization code for each element. The namespace in Microsoft.Web.Services2.Xml will provide usefull services in this area. Carefully examine the spec to see if you need to derive from OpenElement (allowing any (elements) and @any (attributes)) or OpenElementElement (allowing only any (elements)). The structure of these element classes smells like what xsd.exe /c would generate for you (instead of attributes, think deriviation and add the implementation of an IXmlSerializable look-a-like). If the spec exposes service methods, then add a <spec>Service class (as you would implement a regular webservice using WSE 2.0) and provide the implementation for those methods using the element classes you've created. If the spec requires the use of custom headers, derive from SoapInputFilter and SoapOutputFilter (found in Microsoft.Web.Services2) and handle the headers (again) using the element classes.

    In a follow-up post I'll discuss where soap faults and policies go...

    Posted Jun 28 2004, 12:03 AM by yreynhout with 1 comment(s)
    Filed under: ,
More Posts Next page »
Terms of Use