December 2006 Entries
Red gate software is good but the bundles and pricing are unreasonable for the small biz developer who just needs some automation of mundane synch tasks between Dbs.
So I looked into Sql Delta to see if their product would do what I need. It's less than half the cost and the interface was real easy and within about 15 minutes I had synched up the dbs I needed to and have a project saved to automate it in the future. The trial is a full version and the interface is pretty slick I think.
Check it out at
http://www.sqldelta.com/index.html.
As of SP1 of Sql Server 2005, the 'Select All' for parameter lists (drop downs) is gone. THis post explains why MSFT decided to remove it (and it is stupid) and then the suggest the hack found at this post.
[UPDATE] As of SP2, they put it back in...good grief. Now I have to remove the hacks...
In my previous post I proposed a way of adding Notification messages to a global object that would be observed by Presenters. Upon flushing the current Unit of Work, the Notification messages would be delivered to some implementation of INotificationHandler; this could be a custom web control or some logging or whatever. The point is to eliminate throwing exceptions as the way of messaging from the domain up to the UI.
My first iteration works ok, but I had pushed the registration of the INotificationObserver into my PresenterBase class. Now, I want to be able to have multiple Observers for the notifications gathered during a Unit of Work, so I changed my NotificationManager class (renamed Notifier) and tried to implement a static class similar to how Ayende does so with his Unit of Work class:
public static class Notifier
{
public const string CurrentObserverKey = "CurrentObserver.Key";
public const string CurrentNotificationsKey = "CurrentNotification.Key";
private static string LocalDataObserverKey(IUnitOfWork unitOfWork)
{
return CurrentObserverKey + unitOfWork.GetHashCode().ToString();
}
private static string LocalDataNotificationsKey(IUnitOfWork unitOfWork)
{
return CurrentNotificationsKey + unitOfWork.GetHashCode().ToString();
}
public static void Register(IUnitOfWork unitOfWork, INotificationObserver observer)
{
string key = LocalDataObserverKey(unitOfWork);
if (!Local.Data.ContainsKey(key))
{
Initialize(unitOfWork);
}
Set<INotificationObserver> observers =
(Set<INotificationObserver>) Local.Data[key];
if (!observers.Contains(observer))
{
observers.Add(observer);
}
}
private static void Initialize(IUnitOfWork unitOfWork)
{
Local.Data[LocalDataObserverKey(unitOfWork)] = new Set<INotificationObserver>();
Local.Data[LocalDataNotificationsKey(unitOfWork)] = new Set<INotification>();
unitOfWork.UnitOfWorkFlushed += new EventHandler(Notify);
}
private static void Notify(object sender, EventArgs e)
{
IUnitOfWork unitOfWork = (IUnitOfWork)sender;
Set<INotificationObserver> observers =
(Set<INotificationObserver>) Local.Data[LocalDataObserverKey(unitOfWork)];
Set<INotification> notifications =
(Set<INotification>) Local.Data[LocalDataNotificationsKey(unitOfWork)];
foreach(INotificationObserver observer in observers)
{
observer.Update(notifications.ToArray());
}
Clear(unitOfWork);
}
public static void AddNotification(INotification notification)
{
Set<INotification> notifications =
(Set<INotification>) Local.Data[LocalDataNotificationsKey(UnitOfWork.Current)];
notifications.Add(notification);
}
public static void AddItem(INotificationItem notificationItem)
{
Set<INotification> notifications =
(Set<INotification>) Local.Data[LocalDataNotificationsKey(UnitOfWork.Current)];
INotification notification = null;
if (notifications.Count == 0)
{
notification = new Notification();
AddNotification(notification);
}
else
{
notification = notifications.ToArray()[0];
}
notification.AddItem(notificationItem);
}
public static void AddItem(INotification notification,INotificationItem item)
{
Set<INotification> notifications =
(Set<INotification>) Local.Data[LocalDataNotificationsKey(UnitOfWork.Current)];
INotification target = null;
if (!notifications.TryGetItem(notification,out target))
{
target = notification;
notifications.Add(notification);
}
target.AddItem(item);
}
public static void Flush(INotificationObserver observer)
{
IUnitOfWork current = UnitOfWork.Current;
}
public static void Clear(IUnitOfWork unitOfWork)
{
Local.Data.Remove(LocalDataObserverKey(unitOfWork));
Local.Data.Remove(LocalDataNotificationsKey(unitOfWork));
}
}
INotificationObservers and the INotification objects are mapped to their respective UnitOfWork implementation.
Now the problem arise when there are multiple presenters on a page...very common if you use User Controls as your Views in an MVP setup. I like to have small components to work with so this is very common on my pages. PLacing the registration with the Notifier in teh PresenterBase class will obviously result in the same notifications being delivered multiple times and if yo have a single control for Notification messages on your web page each message will be duplicated. One solution might be to simply prevent duplicate equal messages in the control. But I'd rather have more granular control of who is being observed for notifications so I added another With to apply to my Unit of Work.:
public static partial class With
{
public static void UnitOfWork(IUnitOfWork unitOfWork, INotificationObserver observer, Proc method)
{
if (observer != null)
Common.Notifier.Register(unitOfWork, observer);
try
{
method();
unitOfWork.Flush();
}
catch
{
//Do something
}
}
public static void UnitOfWork(INotificationObserver observer,Proc method)
{
UnitOfWork(Common.UnitOfWork.Current,observer, method);
}
public static void UnitOfWork(Proc method)
{
UnitOfWork(Common.UnitOfWork.Current, null, method);
}
}
No big deal here, just running a delegate within a unit of work (typically the Current) while accepting registrations for the INotificationObserver and then flushing out the Unit of Work.
To implement this in my Presenter method (remember that the Presenter implements INotificationObserver) now, it might look like this:
public void AddPerson2()
{
With.UnitOfWork(this,
delegate
{
//Do some stuff in the service layer or whatever
_addCommand.Execute(Person);
});
}
The unit of work details and notification registration is handled for me and if I need to change the way I deal with it it shoul dbe a snap later on.
Comments?
So I am playing around with implementing a way to send messages up from my Domain to my UI without try..catch blocks (exceptions). I am using DTO's that implement a Notification object for communicating messages through the flow of processes. However, this sometimes requires copying message from one objet to another and it seems to be a hack to do so. This is due to the return of only one object from methods, assuming I am not going to implement out parameters on all my methods and I don't want to always throw exceptions for messaging purposes. I think bad user data is expected so these kind of occurences don't warrant an exception...But how to create a consistent way of sending messages up from my Domain layer up to my UI without exceptions or hacks?
I got to thinking that I since I am implementing the Unit of Work pattern, why not simply have an association with some kind of Notification Manager take care of gathering and delivering all these messages? I am using an implementation of IUnitOfWork from Ayende's Rhino Commons . A static UnitOfWork class manages the Current Unit of Work and this is what I want to attach my Notification to. So let's see what happens.
To begin, I am sending notifications through an object that implements my INotification interface:
public interface INotification
{
IList<INotificationItem> Items { get;}
bool HasItems { get;}
bool HasErrors { get;}
void AddItem(INotificationItem item);
void Clear();
IEnumerable<INotificationItem> GetBySeverity(params NotificationSeverity[] severity);
}
For my web app, I have an INotificationHandler that simply parses each INotification implementation and writes the messages to a standard Message control from my presenter. I won't show that code here. Just suffice to say that the PresenterBase from which my Presenters derive contains a reference to an INotificationHandler implementation and it writes to the web page.
IUnitOfWork looks like this after I added an event called UnitOfWorkFlushed like so:
void Flush();
ITransaction BeginTransaction();
ITransaction BeginTransaction(IsolationLevel isolationLevel);
event EventHandler UnitOfWorkFlushed;
When I want to end my Unit of Work, this event will get fired.
Now I am going to implement the Observer pattern to hook into my Unit of Work so first my INotificationObserver interface:
public interface INotificationObserver
{
void Notify(params INotification[] notifications );
}
My Presenters will all implement this INotificationObserver interface so that when the UnitOfWork is flushed the Presenter can handle how any notifications are shown to the user. But I need to register the observer WITH something.
Now, I don't want to mix my Unit of WOrk responsibilities with Notification responsibilities...that smells to me. The event I implemented avoids that kind of commingling of responsibilities. What I want is to have a way to access my NotificationManager from everywhere in my app, so I implement a (Singleton) Notification manager that has a dictionary of IUnitOfWork mapped to my INotificationObservers:
public class NotificationManager
{
#region Singleton Instantiation
NotificationManager() { }
public static NotificationManager Instance
{
get{ return Singleton.instance; }
}
class Singleton
{
static Singleton() { }
internal static readonly NotificationManager instance =
new NotificationManager();
}
#endregion
private IDictionary<IUnitOfWork, INotificationObserver> _hash =
new Dictionary<IUnitOfWork, INotificationObserver>();
private IDictionary<IUnitOfWork, List<INotification>> _notifications =
new Dictionary<IUnitOfWork, List<INotification>>();
public void RegisterHandler(IUnitOfWork unitOfWork,INotificationObserver observer )
{
lock (_hash)
{
_hash.Add(unitOfWork, observer);
}
unitOfWork.UnitOfWorkFlushed += new EventHandler(Notify);
}
private void Notify(object sender, EventArgs e)
{
IUnitOfWork unitOfWork = (IUnitOfWork)sender;
INotificationObserver observer = _hash[unitOfWork];
observer.Notify(_notifications[unitOfWork].ToArray());
}
public void AddNotification(INotification notification)
{
_notifications[UnitOfWork.Current].Add(notification);
}
public void AddItem(INotificationItem notificationItem)
{
if(_notifications[UnitOfWork.Current].Count==0)
_notifications[UnitOfWork.Current].Add(new Notification());
_notifications[UnitOfWork.Current][0].AddItem(notificationItem);
}
}
Within the constructor of my PresenterBase, I can register it along with the UnitOfWork.Current with the NotificationManager and then any INotificationItem messages I need to add throughout the course of a Unit of Work will be added to the appropriate Notification.
NotificationManager.Instance.RegisterHandler(UnitOfWork.Current, this);
Notice in the RegisterHandler method in the NotificationManager that I wire up the IUnitOfWork.UnitOfWorkFlushed event to its Notify method. The Notify method simply grabs the appropriate INotificationObserver implementation and calls its Notify method, passing in all the Notifications that were gathered during the course of the Unit of Work. Though not shown, the clean up of these NOtifications should be done at this time as well. My PresenterBase simply iterates all these INotifications and parses them to the view:
public void Notify(params INotification[] notifications)
{
foreach(INotification notification in notifications)
{
NotificationHandler.Parse(_view, notification);
}
}
What is nice is my INotificationObserver doesn't have to be some kind of View helper...I could pass in a logger as an INotificationObserver as well and let it write messages to a text file in its own Notify() implementation.
I just drummed this up last night, but can anyone see any fatal flaws in my design here? It almost seems to simple yet I can't think of why it would break.Comments would be appreciated!
I decided to post some things which I had to overcome in order to be an effective user of NHibernate before I forgot. My first post dealt with the first fundamental paradigm shift which I needed to grasp which was the difference between Data-Centric and Object-Centric Domain modeling. I noted that the line between them isn't always 'cut and dry' but that's the best way I can express the difference between approaching business solutions with a data model in mind vs. solving business needs with a rich object model that assumes that mapping to persistence can happen.
This assumption, though, might be an erroneous one if you choose an Object Relational Mapping (OR/M) tool that doesn't support the richness your domain demands. That's why looking back I am glad that I chose to dive into the NHibernate camp. Not that there are not other good tools out there, but I have thrown some complex requirements at it and have found it more than able to meet my business need instead of the other way around. But I did at least try other tools first and the next paradigm shift in my mind that began forming had to deal with how I perceived persistence of objects:
INHERITANCE STRATEGIES FOR PERSISTING OBJECTS TO A DATABASE (OR OTHER STORE)
Coming out of the purely data-centric fog of Microsoft documentation left me appalled when I discovered how Very Important People like Martin Fowler proposed to persist objects to a database. Being convinced that the Holy Grail is Database normalization, it is understandable why I considered dropping anything to do with OR/M solutions that proposed that an entire inheritance hierarchy be represented in a single table. "But that means some of my columns will be NULL and that is bad relational modeling." That's what I'd read everywhere and then along comes OR/M and says..."Yeah that's what that means...so what".
This dilemma emerged first because of confusion about duplication and redundancy. I'd read that one of the driving benefits and goals of Object-Oriented Principles (OOP) was to reduce duplication of code and promote reuse. Basically, I didn't understand the notion of Value Objects versus Entities from the Domain-Driven Design (DDD) camp and so thought All Things in my database should never be reference by their values, but rather by their surrogate key. The notion of Aggregate objects was foreign to me and so I'd spend brutal hours trying to be a database designer while sweating because I was going to have to write and maintain the data access code to stick this in my 'objects'. For example, if I had a Contact object that needed to have an Address, I only saw strict rules about having the same Address only listed once in a table(s) because that would be representative of the 'real world'...only one place can be, well, in a place at a time right? While that may be suitable for scenarios, there are times when that simply is not necessary and can be a Pandora's box to attempt to preserve the uniqueness across all of the domain. The big difference is this...I was making my decision not based on what the business rules and needs stated but by what I thought the technology should look like (ie, beautiful table structure).
All of that is to say that the impedance mismatch was something I was just beginning to unearth and my first hurdle was Inheritance. Now, my Design toolbox was (and I think still is) quite empty...the hammer called Inheritance was beloved to me and my elegant Stored Procedures nurtured the affair I had with it. When I downloaded Paul Wilson's ORMapper I was startled to find that subclassing while preserving normalization was not the Holy Grail. In fact, the samples had Phones and Addresses in the same table. WHAT!?! How dare he?! "Aren't these supposed to be logically separated into different tables?"!
There were a few key things I needed to learn and grow up in:
There are different ways to represent inheritance in a database
See NHibernate's documentation for a good description of them. You can ignore the NHibernate specifics and still get a grasp of the strategies. I think it is important to have a tool that at least supports these strategies for mid- to large- size applications. Smaller applications may not require this sophistication. Also see Martin Fowler's PoEAA book...a catalog of patterns (brief) is here.
Inheritance is not always the answer to extending an object's behaviour or use
In fact, when applying Domain Driven Design principles it seems to be an intention and not an assumption. Instead of knee-jerking your design into inheritance just because some methods or properties are shared between objects, look deeper into your model and see if Aggregation or Composition don't suit your intentions better. Without noticing, I have found that subclassing to me is much rarer than when I first began. I discovered that some OR/M tools do not support inheritance across multiple tables (Joined-Subclass strategy) but now I realize that THIS MAY NOT BE A BIG DEAL. For larger apps I definitely think that should be a feature, but not all apps are that sophisticated. There is much more to say on this topic, but the point here is simply that inheritance is not always the answer and so a simple data mapping solution might be feasable.
Normalization might be prettier, But...
if you are going to be a stickler on performance representing a whole Inheritance Hierarchy in the same table might be faster, according to people smarter than me.
The "Stored Procedures are the only way to be secure" notion is a myth.
'Nuff said.
Resources:
My SRS installation wasn't playing nice with IIS 6 so I decided to uninstall the service. I kept getting this error while uninstalling tho:
The setup failed to read IIsMimeMap
I looked through the logs and they were...daunting and useless.
Ultimately, I needed to Stop the DefaultWebSite on IIS . STOPPING IIS SERVICE DOESN'T FIX THIS PROBLEM. You actually have to go to the DefaultWebSite node and Stop.
Here is the forum post that helped me:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=199180&SiteID=1
This is a known bug and according to this post, this issue will be fixed in SP2 of SQL Server 2K5.
I have been using NHibernate for about a year now and have become very comfortable with many of its nuances to meet the requirements my current project's domain has presented. I have a long way to go! I am at a point, though, where I am starting to make some assumptions regarding what developers know or don't know about one of the most important decisions in their application - data access. Before I forget what I had to learn to become effective, I want to begin logging some of the things about using NHibernate, my OR/M of choice, as if I were writing to myself a year ago.
I work by myself and have learned- for better or worse, everything on my own through lots of head scratching and a slough of great blogosphere writers to whom I am indebted. That said, Specifically, I want to write about the conceptual and impedence difficulties which I discovered coming from a mountain of Microsoft 'best practices' articles , application blocks, etc. I am not at all interested in slamming Microsoft...frankly I tire of really talented software developers only blogging about how evil Microsoft is while not contributing any meaningful snippets of useable information to the community in their posts. But there was a dramatic difference of design assumptions which I needed to uncover in order to work with an OR/M like NHibernate.
Before beginning here are some things I want to log about (off the top of my head):
- Impedence mismatch between Domains-which-use-objects (not DataSets) and Relational concepts (ie, normalization)
- What a 'data layer' is and what it is not - the differences between conceptual and physical layers
- Things to avoid when embracing an OR/M - pick a tool and then use it for its intended purpose
- What a 'Domain' is and how to relate to it from your ORM
- Getting data from here to there but without making your code look like it should have meatballs on it
DATA-CENTRIC versus OBJECT-CENTRIC
Tonight, I just want to note the first thing I had to overcome. Microsoft uses lots of terminology borrowed from OOP practicioners and even goes so far as to promote applying OOP in your applications, but their whole 3-tier architecture thing would always confuse me. On one hand, I'd read that I shouldn't have so many dependencies and then I'd only find code that had DataSets getting filled up in code-behind web pages. "AAAARGH!" I'd say...you mean each time I have to make a change to my DataSet I have to change my ADO.NET code and then my controls which bind to them? On top of that I am supposed to have validation and something called a Eunuch At Work...eh....Unit of Work? The problem was, I didn't understand where Microsoft was coming from in solving business problems. This was a battle between Data-Centric 'domains' and Object-Centric domains and I was becoming a casualty.
Everything I was reading about the richness of OOP just FELT right to me, but I couldn't find a single full blown sample application that actually used lots of these objects. I just saw some helper objects that performed actions on DataSets and lots of repetitive ADO.NET code with helpers for that. I'll share more how I came to use an ORM later, but I finally had to realize that I simply wasn't going to find what I was looking for in Microsoft documentation or in most of her very visible writers-of-books. Objects, it seemed to me, just carry property values from the database to the web controls. That didn't feel right, but who am I?
Nowadays, I think of Microsoft as being data-centric in their approach to solving business problems. The majority of samples whether online or in really expensive books have data getting stuffed into a DataSet from home-grown ADO.NET code after writing sometimes elaborate Stored Procedures. In other words, the assumption is always, "Golly...you need to have that 'object' geterself loaded wit dat der data from de sql server, so jes sit down and write yerself out some ado.net gotcha code and bind the returned set into one of our controls." Ok...I am not interested in the DataSet debate, but the problem I kept having was where I'd read about Object-Oriented Principles being driven by a desire to encapsulate and reduce repetitive code all the while repeating tons of code.
I work by myself and maintainability is more important to me than speed. Ironically, having finally come to understand the richness a robust domain model offers, I am faster than I ever was writing acres of ADO.NET and data-layer-coupled web forms. Change isn't scary to me anymore. Now, it's fun.
An example of the difference in these approaches follows.
I need to write a client relationship management solution (CRM) for my project. Something kind of light...not too heady. So where do I start?
DATA CENTRIC
In the 'old days' I'd leap onto my white board and start drawing out my tables, identifying the various properties each 'object' will need along the way being very careful to at least be 3rd norm all the way. Woohoo! I am a DB STUD! Awesome! Now, let's write the Data Access code to populate a...um...DataSet? Well, I was hoping that my Person and Entity classes could subclass from a Contact base class (that's the only OOP trick I know). What's the difference between a typed and untyped dataset? Wait a minute, I read somewhere that datasets are slow and then this other Famous Guy Who Writes Lots of Books says he doesn't ever use DataSets. Dagnabbit! Ok...let's just inherit from an untyped DataSet and we'll have the column names the same for both types of Contacts. Feels funny, but I gotta do something....
Soon, I would have written lots of code, stored procedures (since I had read that they are the only secure way of doing things...) and haven't even gotten around to actually implementing a thing I heard of called 'Business Rules'. This, to me, was the Data-Centric approach to solving problems. Now...there are some who work this way and have had lots of success and if it works for them, I am glad. I found my way of working to be more effective with the opposite approach though.
OBJECT CENTRIC
Now, before I leap to the white board and start identifying loads of properties and how the relational model should look, I leap into a Test and start to flush out what I NEED and how I'll make it WORK even if there weren't ever a thing called a database. My emphasis changes to identifying , weaving, and enforcing BUSINESS RULES and my data access is a supporting role to my Domain needs. What the objects in my code need from a Database my ORM provides, not vice versa. Instead of starting with a table called Person and making it relate to Address and Phone and Email tables as if all were equals, now I start with a simple class called Person and determine whether my IAddress, IPhone, and IEmail implementation will be indeed autonomous with their own identity (Entity) or simply be recognized by their unique values (Value Object). HUGE difference in approach that ultimately makes me write code instead of stored procedures that I can't refactor very easily and makes my ideas resilient to change.
This is a very brief contrast between their approaches that I uncovered but should at least indicate that when I thinking in terms of Objects and not Data I am thinking in terms of the BUSINESS driving my decisions. I make the assumption that the technology will support whatever business need I have. Conversely, when I have to conform my objects to meet my relational requirements (ie, normalization) my business concerns get squeezed in between the technology solution.
So that was the first growing pain - either be Data Centric or be Object Centric. But don't be Data Centric while calling your portable data structures a rich Domain Model. I am sure this is reductionistic, but I at least needed to know there was a difference in ways to tackle business problems in software.
Jeremy Miller is one of those rare blogs that generates more light than heat. He's published a useful post for refactoring guidance.
I wanted to test what would happen with different SQL messages in my app. Based on their error codes, I'd wrap a friendlier message around them and send em on up.
Problem is, SqlException is sealed AND has no public constructors. Great. How the heck do you test that?
One might try something snappy like this :
try
{
SqlConnection conn = new SqlConnection("server=.;database=YOURDB;Integrated Security=true;");
conn.Open();
SqlCommand cmd = new SqlCommand("raiserror(2601,16,1)",conn);
cmd.ExecuteNonQuery();
}
catch (SqlException ex)
{
sql = ex;
}
Assert.AreEqual(2601, (