Comments on: Changing type, the state pattern and LINQ to SQL http://damieng.com/blog/2009/01/05/changing-type-the-state-pattern-and-linq-to-sql?utm_source=rss&utm_medium=rss&utm_campaign=changing-type-the-state-pattern-and-linq-to-sql A .NET developer in silicon valley Sun, 25 Dec 2011 15:10:30 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Gareth Jones http://damieng.com/blog/2009/01/05/changing-type-the-state-pattern-and-linq-to-sql#comment-32574 Gareth Jones Thu, 17 Dec 2009 20:34:11 +0000 http://damieng.com/?p=1126#comment-32574 While I think it's true that its a smell if entities in a LOB application change their type, I think it's actually pretty common in a knowledge manipulation/creative application. I've lost count of the times I've wanted to change a geometry to an image or a struct to a class or similar choices. The state pattern can work here, although it primarily concerns itself with behavior. In these knowledge-based apps, data frequently changes as well, so you need to have some sort of exchange mechanism where you can move the subset of data that is applicable across. Also the object then needs to change its set of attributes for later manipulation. That implies that you have a dynamic enough typing mechanism that the aggregated state object can appear to project its properties up to the parent object for anyone that cares - otherwise you're breaking your encapsulation. I've never tried mapping that to a RDBMS - interesting topic. While I think it’s true that its a smell if entities in a LOB application change their type, I think it’s actually pretty common in a knowledge manipulation/creative application.

I’ve lost count of the times I’ve wanted to change a geometry to an image or a struct to a class or similar choices.

The state pattern can work here, although it primarily concerns itself with behavior. In these knowledge-based apps, data frequently changes as well, so you need to have some sort of exchange mechanism where you can move the subset of data that is applicable across. Also the object then needs to change its set of attributes for later manipulation. That implies that you have a dynamic enough typing mechanism that the aggregated state object can appear to project its properties up to the parent object for anyone that cares – otherwise you’re breaking your encapsulation. I’ve never tried mapping that to a RDBMS – interesting topic.

]]> By: Damien Guard http://damieng.com/blog/2009/01/05/changing-type-the-state-pattern-and-linq-to-sql#comment-10814 Damien Guard Thu, 08 Jan 2009 23:01:30 +0000 http://damieng.com/?p=1126#comment-10814 Unfortunately business rules these days are very complex and the database is unsuited to advanced programming environments/language/contructs that would be required not to mention the issues and costs involved in scaling those out compared to putting the logic in business layers. It's the same server-v-client argument that has caused the swings back and forth over the last x number of years. [)amien Unfortunately business rules these days are very complex and the database is unsuited to advanced programming environments/language/contructs that would be required not to mention the issues and costs involved in scaling those out compared to putting the logic in business layers.

It’s the same server-v-client argument that has caused the swings back and forth over the last x number of years.

[)amien

]]> By: Robert Young http://damieng.com/blog/2009/01/05/changing-type-the-state-pattern-and-linq-to-sql#comment-10812 Robert Young Thu, 08 Jan 2009 22:20:47 +0000 http://damieng.com/?p=1126#comment-10812 It's still too bad that most ORM folk come from the Coding world rather than the Database world. For example, Hitting the discriminator directly has 3 cases which you worry about. As one from the Database world, the answer is straightforward: these are constraints, stored in the catalog as plain text, and can be read from said catalog either at compile time or run time or both and turned into local Edit Checks as desired. There are products in existence which do so. The advantage: by having data and its constraints of record stored together in the Database Engine leaves no room for execution error due to sync-ing among however many tiers one chooses to use. All constraints which are applied in a tier are validated against the catalog. This is the whole point of storing to a RDBMS; storing to bespoke files (xml or VSAM or ...) will always be faster. Less power for coders, but too bad. I just did some looking elsewhere, and it seems that LINQ is not designed to generate validation from the catalog, beyond simple stuff. Really too bad; it would be killer if it did. In the Database world, the Prime Directive: a row is a business rule. Date wrote a book about that, although it is obvious. It’s still too bad that most ORM folk come from the Coding world rather than the Database world. For example,

Hitting the discriminator directly

has 3 cases which you worry about. As one from the Database world, the answer is straightforward: these are constraints, stored in the catalog as plain text, and can be read from said catalog either at compile time or run time or both and turned into local Edit Checks as desired. There are products in existence which do so.

The advantage: by having data and its constraints of record stored together in the Database Engine leaves no room for execution error due to sync-ing among however many tiers one chooses to use. All constraints which are applied in a tier are validated against the catalog. This is the whole point of storing to a RDBMS; storing to bespoke files (xml or VSAM or …) will always be faster. Less power for coders, but too bad.

I just did some looking elsewhere, and it seems that LINQ is not designed to generate validation from the catalog, beyond simple stuff. Really too bad; it would be killer if it did.

In the Database world, the Prime Directive: a row is a business rule. Date wrote a book about that, although it is obvious.

]]> By: Damien Guard http://damieng.com/blog/2009/01/05/changing-type-the-state-pattern-and-linq-to-sql#comment-10807 Damien Guard Wed, 07 Jan 2009 19:44:49 +0000 http://damieng.com/?p=1126#comment-10807 The concept of making the state pattern a first-class citizen in an ORM is an interesting one and if type discriminators are supported then why not? I assume by session you mean the data gateway and identity map? If so, the problem there is when there are multiple references to a single entity object that is now taking part in a unit of work. It would be possible to create a copy of the entities as they participate to ensure changes are isolated and then apply those back to the original entity instance once commited. Having to specifically enroll entities in the unit of work and know they won't propogate out would be a bit of a mind-shift for many but worth it in my opinion. [)amien The concept of making the state pattern a first-class citizen in an ORM is an interesting one and if type discriminators are supported then why not?

I assume by session you mean the data gateway and identity map? If so, the problem there is when there are multiple references to a single entity object that is now taking part in a unit of work.

It would be possible to create a copy of the entities as they participate to ensure changes are isolated and then apply those back to the original entity instance once commited. Having to specifically enroll entities in the unit of work and know they won’t propogate out would be a bit of a mind-shift for many but worth it in my opinion.

[)amien

]]> By: Steve Campbell http://damieng.com/blog/2009/01/05/changing-type-the-state-pattern-and-linq-to-sql#comment-10806 Steve Campbell Wed, 07 Jan 2009 18:30:20 +0000 http://damieng.com/?p=1126#comment-10806 When I was writing a custom-ORM some time ago, I had an identical concept. Boolean flags (like "Active") are the uncommon, simple case. The more general case in an ORM model is that you really have to carefully consider every discriminator value in your types, as to whether it is constant over the lifetime of an instance, or it can change. If it is constant, then inheritance is the simpler pattern. If it is not, then States are a better pattern. In my case, I was able to focus considerable effort on making States into a first-class citizen in the ORM. This enabled things like exposing optimized collections like "Customer.ActiveAccounts", and also having the change of the discriminator automatically move the account from Customer.ActiveAccounts to Customer.NonActiveAccounts. A more realistic example is that you have a status-discriminator with multiple possible values, and that status is stored in a separate table than the main account data. In addition, you have some other discriminator flags. It can easily be that "Active" is a broad concept which must be derived from multiple discriminators. For example, Active is true when "open-flag=true and status!=suspended". Consider the value of an automatically available (not hand-coded) Customer.ActiveAccounts in this context - it is a very low-friction way of working with data. My point is that the State pattern *should* be a first-class citizen in any ORM model. Without it, you have a fair amount of friction (for example having to manually code the simple boolean logic for my "Active" example) and performance issues (because the ORM cannot auto-generate a query for "Active" accounts the way it could if it were a "Type" discriminator). Score -1 for every commercial and open-source ORM I've encountered so far. Does anyone know if there an ORM that even knows about States? While I'm here, does anyone know if there is one that does not couple the orthogonal concepts of Session and Unit of Work? (You can probably tell that I have a very low opinion of the ORMs I have encountered). When I was writing a custom-ORM some time ago, I had an identical concept. Boolean flags (like “Active”) are the uncommon, simple case. The more general case in an ORM model is that you really have to carefully consider every discriminator value in your types, as to whether it is constant over the lifetime of an instance, or it can change. If it is constant, then inheritance is the simpler pattern. If it is not, then States are a better pattern.

In my case, I was able to focus considerable effort on making States into a first-class citizen in the ORM. This enabled things like exposing optimized collections like “Customer.ActiveAccounts”, and also having the change of the discriminator automatically move the account from Customer.ActiveAccounts to Customer.NonActiveAccounts.

A more realistic example is that you have a status-discriminator with multiple possible values, and that status is stored in a separate table than the main account data. In addition, you have some other discriminator flags. It can easily be that “Active” is a broad concept which must be derived from multiple discriminators. For example, Active is true when “open-flag=true and status!=suspended”. Consider the value of an automatically available (not hand-coded) Customer.ActiveAccounts in this context – it is a very low-friction way of working with data.

My point is that the State pattern *should* be a first-class citizen in any ORM model. Without it, you have a fair amount of friction (for example having to manually code the simple boolean logic for my “Active” example) and performance issues (because the ORM cannot auto-generate a query for “Active” accounts the way it could if it were a “Type” discriminator).

Score -1 for every commercial and open-source ORM I’ve encountered so far. Does anyone know if there an ORM that even knows about States? While I’m here, does anyone know if there is one that does not couple the orthogonal concepts of Session and Unit of Work? (You can probably tell that I have a very low opinion of the ORMs I have encountered).

]]> By: Steve http://damieng.com/blog/2009/01/05/changing-type-the-state-pattern-and-linq-to-sql#comment-10802 Steve Wed, 07 Jan 2009 09:53:38 +0000 http://damieng.com/?p=1126#comment-10802 I'd argue that account types are not universally fundamental. The distinction between 'checking' and 'savings' is an American thing, in that there are Federal laws that say you can't pay interest on a checking account. Not so in other countries. In the UK a 'Current' account isn't anywhere near as restricted a definition as a 'Checking' account, and the line between 'Current' and 'Savings' is regularly very blurry. I’d argue that account types are not universally fundamental. The distinction between ‘checking’ and ‘savings’ is an American thing, in that there are Federal laws that say you can’t pay interest on a checking account. Not so in other countries. In the UK a ‘Current’ account isn’t anywhere near as restricted a definition as a ‘Checking’ account, and the line between ‘Current’ and ‘Savings’ is regularly very blurry.

]]> By: Damien Guard http://damieng.com/blog/2009/01/05/changing-type-the-state-pattern-and-linq-to-sql#comment-10799 Damien Guard Tue, 06 Jan 2009 16:31:46 +0000 http://damieng.com/?p=1126#comment-10799 The terms of bank accounts tends to change from time to time, interest rates etc. but I've never had a bank account change it's fundamental type... [)amien The terms of bank accounts tends to change from time to time, interest rates etc. but I’ve never had a bank account change it’s fundamental type…

[)amien

]]> By: Steve http://damieng.com/blog/2009/01/05/changing-type-the-state-pattern-and-linq-to-sql#comment-10798 Steve Tue, 06 Jan 2009 12:01:44 +0000 http://damieng.com/?p=1126#comment-10798 Funnily enough I've had my bank accounts change type many times, due to the bank running promotional new types of account, time-limited sign-ups that then revert to other types etc. But obviously your use of the State pattern could equally be used for that (or the Strategy pattern). The GoF is one book that just keeps on giving. There's actually not a lot of practical difference between the State and Strategy patterns. The only real difference is that Strategy tends to hold no state of its own, it's a pure functional object and can therefore be shared between stateful instances, swapped in and out more freely, while the State pattern is strongly associated with parent stateful structures. Funnily enough I’ve had my bank accounts change type many times, due to the bank running promotional new types of account, time-limited sign-ups that then revert to other types etc. But obviously your use of the State pattern could equally be used for that (or the Strategy pattern). The GoF is one book that just keeps on giving.

There’s actually not a lot of practical difference between the State and Strategy patterns. The only real difference is that Strategy tends to hold no state of its own, it’s a pure functional object and can therefore be shared between stateful instances, swapped in and out more freely, while the State pattern is strongly associated with parent stateful structures.

]]>