Nhibernate Disjunction

As I use NHibernate more, I have been learning a bit about the criteria (very slick) and today I learned a really nice piece of functionality in NHibernate 2.0:

Original Code:

criteria.CreateCriteria(GetFieldName(x => x.MessageStatus))
  .Add(Restrictions.Or(
       Restrictions.Eq(GetFieldName<MessageStatus>(x => x.Status), FailedDeliveringStatus.State),
       Restrictions.Or(
       Restrictions.Eq(GetFieldName<MessageStatus>(x => x.Status), FailedEntryToAwaitingProcessingStatus.State),
       Restrictions.Or(
       Restrictions.Eq(GetFieldName<MessageStatus>(x => x.Status), FailedProcessingStatus.State),
       Restrictions.Eq(GetFieldName<MessageStatus>(x => x.Status), FailedLegacyWriteStatus.State)))));

New Code:

criteria.CreateCriteria(GetFieldName(x => x.MessageStatus))
  .Add(Restrictions.Disjunction()
  .Add(Restrictions.Eq(GetFieldName<MessageStatus>(x => x.Status), FailedDeliveringStatus.State))
  .Add(Restrictions.Eq(GetFieldName<MessageStatus>(x => x.Status), FailedEntryToAwaitingProcessingStatus.State))
  .Add(Restrictions.Eq(GetFieldName<MessageStatus>(x => x.Status), FailedProcessingStatus.State))
  .Add(Restrictions.Eq(GetFieldName<MessageStatus>(x => x.Status), FailedLegacyWriteStatus.State))
  .Add(Restrictions.Eq(GetFieldName<MessageStatus>(x => x.Status), FailedNotificationStatus.State)));

As you can see, much nicer. The Disjunction makes the code much easier to read and modify.

In case you are wondering this is the code for GetFieldName:

    protected static string GetFieldName(Expression<Func<DomainType, object>> expression)
    {
      var name = expression.ToString();
      return Regex.Match(name, @"\.(.*)")
        .Groups[1].Value;
    }

    protected static string GetFieldName<TObjectType>(Expression<Func<TObjectType, object>> expression)
    {
      var name = expression.ToString();
      return Regex.Match(name, @"\.(.*)")
        .Groups[1].Value;
    }

Dev Teach 2009 - Day 3 Session Six

Oren Eini - Advanced Usages of IoC

So looks like this might be more of a questions & answer session. So we are asking the questions right now.

- IOC exists to help manage complexity.

- Many people go to IoC for testing & Mocking. This is incorrect. IoC is actually about managing complexity. The testing/mocking are just side benefits.

5:46 - XML configuration is the root of all evil when it comes to IoC. (Oren says that Women are the root of all evil... his humour is so similiar to Sean's) XML violates the DRY principles. Why are we repeating the name of the class within the XML?

5:50 - I like IoC conventions! So pretty in windsor... mmmm. Using conventions means that every piece of your application behaves in the same manner. This is really cool and allows your developers to "Fall into the pit of success"

5:55 - Depth dive into windsor use.

I'm tired, no more notes!

Cheerio!

Dev Teach 2009 - Day 3 Session Five

Michael Stiefel - Are Agile and Domain Modeling Frenemies?

This guy destroyed my mind last time he spoke. Let's see what comes about this time. (Considering that my minds was destroyed by the last talk)

4:00 - I guess this talk will be more of a discussion rather than a talk. Should still gain something but I imagine that the notes might be difficult

Domain Modeling implies creating most of the domain in advance, this flies in the face of the YAGNI concept. So the question is how can they interact happily.

Dev Teach 2009 - Day 3 Session Four

Mmmm lunch. Not a phenomenal lunch, but not bad.

Greg Young - Unleash Your Domain

The talk is about architecture with a domain driven design applications. Mixing a ddd with service based application.

2:30 - Generally people say that ddd is useful for business applications, since it doesn't matter what the performance is.

Greg says that you can get high performance and use domain models. 20000 calls per second in the application that he was working on.

2:32 - Talking about Audit logs. What happens if you can't prove that your audit is correct? What's the point of the audit? Hansel and Gretal had an audit trail, but the animals eat their audit log, so they were completely lost.

2:34 - State transitions are an important part of our problem space and should be modeled within our domain. There was a specific reason that the state changed.

2:35 - How do explicit state transitions help with auditing? If redo behaviors on an object then you should be able to get back to the state that you had before. Since you have explicit state transitions, you know that your audit log is correct because you are able to recreate the object from your audit log. (I don't know if I am really understanding this myself so forgive me if it makes no sense)

2:41 - So every behaviour on an object is a "command". The model is additive only, you never remove something from the objects, you send a behavior called "Remove 1". If you have many, many commands that need to be put in the audit log, you can use "rolling snapshots", so you mark spots along the chain of behaviors. That way you have specific knowledge of the state throughout it's history.

2:44 - My head hurts.

2:45 - So essentially, if I understand correctly, your database basically only has one table, which is just a list of commands that build objects. Then when we want to partition across multiple machines it's really easy.

2:50 - Since we don't have any state normalized in a database we need to provide this.

A single model cannot be appropriate for reporting, searching and transactional behaviors. Reporting is anything from the database that doesn't mean get the object by id so I can update it.

This is a circular picture.

Map DTO from Domain ->
Edit DTO in UI -> We don't really edit data, we do behaviors on the object. We don't edit a persons address, we move them to a new location.
Send DTO to Server ->
Map Data from DTO to Domain ->
Save Domain Object(s) ->
Repeat

The model that a client needs the data in a distributed system is screen based and different than the domain model.

There is now a picture from the bottom of a golf cup. We are supposed to use a different perspective.

2:55 - Our read data is already stale as soon as we show the data to the user. We don't need consistency on read data because as soon as you show the data then the data has changed. Therefore we can split the queries away from the write and the data. Writes on the other hand require absolute consistency.

2:57 - Getters and Setters are a domain anti-pattern. They are actually the smell of procedural code. Basically I think that we don't have to have getters or setters when we focus on behaviors rather than state. Since we are using the command query separation, we are side stepping the issue of setters. The domain objects themselves should be maintaining their inner state.

3:05 - I am so confused.

3:05 - When the data from your domain context changes, your reporting context should be listening to events thrown by the domain context. Event streaming provides a way for other systems to integrate with us as it allows them to handle information as it comes. Increases system up town.

3:07 - Most Bounded Contexts can interact with relaxed consistency.

"Man acts as though he were the shaper and master of language, while in fact it is language that is the master of man"

Events are past tense, Behaviors are imperative. These events are not to be confused with events from the dot net framework.

Coming into your domain, you have have events and commands, commands you can reject. If you have a problem with the events the problem is with your system.

3:15 - Getters and Setters are an anti-pattern. Avoid them
Relax consistency between systems or you constrain your availability. Your system is only as strong as the weakest link.

A single model is never appropriate for all behaviors within your system. Reporting, searching, and transactional behaviors.


I think I understand... my head kinda hurts but I think I understand. This is a really different way to think about architecture but I think it makes alot of sense.

I want to revisit this post as I need to spend some time to understand it.

Dev Teach 2009 - Day 3 Session Three

D'Arcy Lussier - Architecting Software in Silverlight

Well after the last barn burner, let's see what D'Arcy has to teach!

12:04 - We are going over the fact that Silverlight is different than ASP.NET or WinForms, so you have to ensure that you are not bringing notions from those technologies.

12:06 - What is Silverlight?
- Rich client-side technology
- New platform for creating browser-based applications (3.0 will (maybe) allow for offline support)
- Not a replacement for ASP.NET (or ASP.NET MVC). Silverlight should not be considered an alternative, but rather should be considered complimentary.
- Microsoft is highly invested in this technology.

12:08 - When you are considering Silverlight, you need to think about it first. It is not the hammer that can hammer anything.

#1- Identify the scenario(s) - keep in mind if Silverlight is the right fit.
#2- Understand the tradeoffs.
#3- Be prepared to relearn as Silverlight is a new technology and how you used to do it won't necessarily be the right way.

12:10 - Differences:

ASP.NET - Server Side Technology
WinForms - Client Side Technology with deployment
Silverlight - Client Side Technology with no deployment. While you are not deploying it, there is still a download required, so make sure to think about it.

12:11 - Some guy just razzed on my for typing too loudly. I almost swore at him, but thought that would be unprofessional.

Persistence
ASP.NET - Cookies, Session, QueryString, Database
Winforms - Local file system, Database
Silverlight - Isolated storage
-> You don't get any direct connections to databases. You need to WCF to get your domain stuff. You also don't have the ability to access the filesystem. Silverlight applications get 1mg of storage space, if you need more, then you will need to prompt the user. What happens if they don't let you? They could also disable the isolated storage all together. There is db4o which can run within the isolated storage to give you a DB if you want to.

12:19 - Communication
You have to use WCF to communicate outside of a Silverlight Application

Security
ASP.NET & WinForms are rich and mature.

Silverlight
- Client Side - Sandboxed
- Client Side - Restricted Resource Access
- Client Side - Open User Access (if anybody can browse to the .xap file, they can access the application, if you are using ASP.NET you might want to use the ASP.NET security to provide access security)
- Communications - Cross Domain Complexity (if you want to access anything outside of the domain (devteach.com -> amazon.com) sounds complex, there is a cross domain file.

12:26
Support
ASP.NET - Well supported.
WinForms - RIP... have you met my friend WPF?
Silverlight - Moving Fast, Relies on Community. Therefore, there isn't quite as much support available for it. The silverlight team is committed to doing quick turnaround on features. It should move fast! Silverlight 3 is looking like it will be release in July. There isn't the established base that you would find in the other two technologies, so it will take longer to build the software.

12:30
Tooling
Blend is a must for 2.0 but will still be important for 3.0
Don't underestimate learning curve for XAML of how properties, binding, etc, work within Silverlight.
Blend is the microsoft tool to create XAML and is supposed to work really well.
2010 will be better than 2008 as far as XAML support.

12:33
Architecture
Silverlight
Architecture patterns like MVVM which focus on utilizing databinding features of Silverlight. MVVM is worth learning about because it allows better databinding. In Silverlight (and WPF) you don't have the choice but to use databinding. So MVVM was created to deal with the issues that we used to have in winforms with databinding.

Guidance like Prism (Composite Application Block) from Microsoft on how to separate concerns in an application.

12:48
Question time!

If your code isn't obfuscated in Silverlight, then the users can see all your Intellectual Property. WCF would solve most of this problem.

LUNCH TIME!!!

Dev Teach 2009 - Day 3 Session Two

James Kovacs - Convention-over-Configuration in a .NET World

Here we are again with James Kovacs. Should be another pretty interesting talk.

10:34 -
.NET is historically configuration based
- App/web.config
- IoC config
- ORM config
- Mappers
- Event Handlers

10:35 -
Ruby (Ruby on Rails) was a game changer, as it is mostly convention based. Very convention based, as long as you do the right thing, then it will just work. It appears that there are many things that allow for pure convention, if you want to add a field to your class, you just need to add the column to the database.

10:42
Supporting Conventions
- NHibernate/Fluent NHibernate
- AutoMapper (Very recent)
- Castle Windsor
- ASP.NET MVC
- FubuMVC
- jQuery/jQuery UI

10:58
James spent the last 20ish minutes explaining the above technologies. I like AutoMapper concept.

11:08 - AutoMapper is super slick.

Automapper really only flattens structures (domain -> dto/view object), you can't go the other way as generally you shouldn't be setting domain values without some thought/validation.

11:21 - you can map to an interface using AutoMapper, not really sure of the value, but it's there.

11:45 - rest of the talk focused on nHibernate Fluent Configuration. Interesting talk, but I've seen most of it before. except Automapper. Very cool.

Dev Teach 2009 - Day 3 Session One

Oren Eini - Building Domain Specific Languages in Boo

What are Domain Specific Languages?

9:04 - Second introduction to DSLs

Domain Specific Languages split the How and the What from the Intent.

9:06 - Oren wrote a book with this same name

DSL Types -
Graphical DSL
External DSL
Internal /Imbedded DSL (a DSL written in the language you are writing with ie: C#)
Fluent Interface (Oren does not really like Fluent interfaces as he feels they are overused and not necessarily understandable).

9:11 - We need to decide whether or not it is valuable to use a DSL, because they can become complex in complex cases (ie: complex SQL)

9:16 - Internal DSL
Based on existing (dynamic) language
Uses language ambiguities
Allows us to leverage the existing language strengths.
Common Languages
-> Boo
-> Ruby
-> Python
-> Lisp
-> Etc.

9:18 - Boo
Python derivative
Statically Typed
Runs on the CLR
Open Compiler architecture
Extremely malleable


9:20 - Boo Code Sample

using session = sessionFactory.OpenSession():
  people = sess.Find("from Person")
  for p as Person in people:
    print (p.Name)

9:25 - Sample DSL

OnCreate Account: Entity.AccountNumber = date.now.Ticks
OnCreate Order:
  if Entity.Total > Entity.Account.MaxOrderTotal:
    BeginManualApprovalFor Entity

Account and Order are already part of my domain model

Boo vs C#

Boo
OnCreate Account: Entity.AccountNumber=date.Now.Ticks

C#
OnCreate(typeof(Account), delegate{Entity.AccountNumber=DateTime.Now.Ticks});

9:26
Implementation - Use a base class DslBase. Time for a code demo!

9:28
So your boo code is run through the CRL and you get all the power you have with the .NET framework. So you can walk both through your DSL language and see what's actually going on in your C# code.

9:39
When you are writing a DSL you are not trying to write in English. English is too ambiguous. You have to write in a dialect that is clear to a machine.

ie:
if Entity.Total > Entity.MaxTotal
vs
Entity's Total bigger than Entity's Max Total

We are not trying to make the DSL writeable for the business. Just readable.

9:50
So there is a bunch of C# code that needs to be implemented in order to allow for the DSL. It seems somewhat complex, however, would only need to be written once in order to allow for use with all DSLs created within a system. Again as Oren said, we need to be aware that there is a cost to creating a DSL. If the cost of the DSL outweighs the benefit then you should look at alternatives.

10:03
The demo has been going on for a while. It has been interesting, but I will need to look deeper into the topic.