March 2004 - Posts
Yesterday I posted a list of Xml links that I came across that seemed to contain some useful information. This morning I changed the Xml processing code in an application based on
some recommendations from
Daniel Cazzulino and saw awesome results. By changing from a XmlDocument.SelectSingleNode() with a basic XPath query to XPathNavigator.Select() with a compiled XPath query I almost doubled the responsiveness of the application. Simply converting from SelectSingleNodes() on an XmlDocument to XPathNavigator.Select() had a very minor affect, however, by leveraging Daniel's
DynamicContext class I almost doubled the responsiveness of the app. Nice work Daniel!
I saw this list of links come across the Win Off Topic mailing list in regards to someone asking about PDA's and thought I should grab them in case I need them....like tonight when the UPS man comes :-) Anyone have any other links I should keep bookmarked?
For code see [1], for other stuff (reviews, software) see other links.
For free soft see [5]. [7] is totally essential so install, to this
before any soft. [9], [8] are my favorite software.
[1] http://www.opennetcf.org/
[2] http://www.brighthand.com/ppc/index.php
[3] http://www.the-gadgeteer.com/
[4] http://www.pocketpcpassion.com/
[5] http://www.freewareppc.com/
[6] http://www.ipaqsoft.net/
[7] http://www.lakeridgesoftware.com/wisbar/screens.html
[8] http://www.pocketinformant.com/
[9] http://www.resco-net.com/explorer.asp
If your developing web services you should consider doing contract first development. To help, be sure to check out Christian Weyer's WSContactFirst.
If your developing web services you should consider doing contract first development. To help, be sure to check out Christian Weyer's WSContactFirst.
I came across two interesting Wiki related items this weekend:
1) “WikiTalk is a language for including dynamic content in FlexWiki.WikiTalk is a simple object-oriented language that advanced users can use to add dynamic behavior to their FlexWiki FlexWiki topics.“ - FlexWiki.org
2) Confluence is a knowledge-management tool designed to make it easy for a team to share information with each other, and with the world.
I've thought about getting a Pocket PC for a while and kept putting it off since I'm not sure how much I'd actually use it. The new HP iPAQ Pocket PC h4350 is very tempting. Chris Anderson was given one at MDC, anybody want to give me one? :-)
In a domain model we have behavior (and business logic) within our business objects. In contrast with the Manager (Service) Model our business objects have no behavior and no business logic (except possibly validation logic). A “Manager” class provides the behavior and applies the business rules. Let's take a look at an example of each:
Domain Model:
public class Customer {
// properties
public string FirstName;
public string LastName;
// methods
public bool Save();
public bool Delete();
public Customer Get(int id);
public CustomerCollection Find(Query aQuery);
}
Vs.
Manager Model
public class Customer {
// properties
public string FirstName;
public string LastName;
} // Note: no behavior
public class CustomerManager {
public bool SaveCustomer(Customer aCustomer);
public bool DeleteCustomer(Customer aCustomer);
public Customer GetCustomer(int customerID);
public CustomerCollection Find(Query aQuery);
}
As you can see using the Manager Model introduces another class into the mix that performs all the operations on your business objects. An important thing to note is that the Manager Model and Domain Model are not mutually exclusive. We could very easily have this:
public class Customer {
// properties
public string FirstName;
public string LastName;
public bool Save();
public bool Delete();
public Customer Get(int id);
public CustomerCollection Find(Query aQuery);
}
public class CustomerManager {
public bool SaveCustomer(Customer aCustomer) {
// do pre save stuff, apply aspects, etc.
aCustomer.Save();
// do post save stuff, apply aspects, etc.
}
public bool DeleteCustomer(Customer aCustomer) {
// do pre delete stuff, apply aspects, etc.
aCustomer.Delete();
// do post delete stuff, apply aspects, etc.
}
public Customer GetCustomer(int customerID) { // etc. }
public CustomerCollection Find(Query aQuery) { // etc.}
}
Essentially with this approach the Manager (Service) object is working as a facade. This approach is often beneficial when you have a significant investment in the domain model and want to add a service layer on top. Rather then just targeting the Customer, the service would likely be broader in scope and include other methods for handling other types of objects. The scope that the service covers will depend on the application and the anticipated use of the objects within your application.
How else are people using the Manager model and Domain model together. When does it work? When doesn't it? Anyone else care to shed some light on how they define each?
In a domain model we have behavior (and business logic) within our business objects. In contrast with the Manager (Service) Model our business objects have no behavior and no business logic (except possibly validation logic). A “Manager” class provides the behavior and applies the business rules. Let's take a look at an example of each:
Domain Model:
public class Customer {
// properties
public string FirstName;
public string LastName;
// methods
public bool Save();
public bool Delete();
public Customer Get(int id);
public CustomerCollection Find(Query aQuery);
}
Vs.
Manager Model
public class Customer {
// properties
public string FirstName;
public string LastName;
} // Note: no behavior
public class CustomerManager {
public bool SaveCustomer(Customer aCustomer);
public bool DeleteCustomer(Customer aCustomer);
public Customer GetCustomer(int customerID);
public CustomerCollection Find(Query aQuery);
}
As you can see using the Manager Model introduces another class into the mix that performs all the operations on your business objects. An important thing to note is that the Manager Model and Domain Model are not mutually exclusive. We could very easily have this:
public class Customer {
// properties
public string FirstName;
public string LastName;
public bool Save();
public bool Delete();
public Customer Get(int id);
public CustomerCollection Find(Query aQuery);
}
public class CustomerManager {
public bool SaveCustomer(Customer aCustomer) {
// do pre save stuff, apply aspects, etc.
aCustomer.Save();
// do post save stuff, apply aspects, etc.
}
public bool DeleteCustomer(Customer aCustomer) {
// do pre delete stuff, apply aspects, etc.
aCustomer.Delete();
// do post delete stuff, apply aspects, etc.
}
public Customer GetCustomer(int customerID) { // etc. }
public CustomerCollection Find(Query aQuery) { // etc.}
}
Essentially with this approach the Manager (Service) object is working as a facade. This approach is often beneficial when you have a significant investment in the domain model and want to add a service layer on top. Rather then just targeting the Customer, the service would likely be broader in scope and include other methods for handling other types of objects. The scope that the service covers will depend on the application and the anticipated use of the objects within your application.
How else are people using the Manager model and Domain model together. When does it work? When doesn't it? Anyone else care to shed some light on how they define each?
In my previous post I stated that I *think* I'm starting to move toward the Manager Model. One of the reasons for this is because I want consistency in my API's. I don't want some actions to be performed via a entity object, and other actions to be performed through a Manager. If I do fully embrace the Manager Model the question now becomes do I complete abandon my domain model, or does it just become lighter? My initial thought is that it just becomes lighter. The business logic and workflow for the actions that I perform within my applications will move out of the domain model and into the manager model. The thing I struggle with is the amount of behavior to pull out of my entity objects. I've grown somewhat attached to the behavior, the ability to call .Save(), .Delete(), .FindOne(), .FindAll() right off my entity objects is something I like. Besides just being something I like, the existing behavior also would make the implementation of my Manager (we're really talking about services here so why do I keep calling them managers?) Service a lot easier.
public class CustomerService {
public CustomerSaveResponse SaveCustomer(Customer aCustomer) {
if(aCustomer.Save()) {
/// blah blah
}
return new CustomerSaveResponse();
}
}
Should behavior on my entity objects stay or go?
I finally got around to reading some of the follow up comments to Frans “Does SOA require Object Message Mappers? It depends.” post. The comments can be summed up as follows:
+1 for Domain
- Jimmy Nilsson
- Mats Helender
- Yves Reynhout
+1 for Manager
- Frans Bouma
- Jimmy Nilsson
- Udi Dahan
- Andres Aguiar
- Mats Helender
- Yves Reynhout
Where exactly do I fall in the voting? While I'm still trying to figure it out for sure, I think I fall somewhere in the middle. On the one hand I like having behavior on my entity objects. When I need to save a Customer I like being able to do customer.Save(). When I need to give an employee a raise I like employee.Raise(.50). With that said I think I'm slowly moving toward a Manager model, here's why:
- Certain business actions need to go through a manager. To stay consistent using a manager for everything may make more sense.
- Managers allow you to separate the business logic from the entities. This allows you to apply different business rules depending on the operation.
- Managers allow you to apply aspects easier. Introducing logic to apply aspects within my entity objects is not something I'm comfortable with.
- Business processes that involve many different entities make more sense in a manager then in your entity objects. Coupling is bad, right?
- It's more in line with SOA, after all a manager model could also be called a service model.
What's your vote?
I finally got around to reading some of the follow up comments to Frans “Does SOA require Object Message Mappers? It depends.” post. The comments can be summed up as follows:
+1 for Domain
- Jimmy Nilsson
- Mats Helender
- Yves Reynhout
+1 for Manager
- Frans Bouma
- Jimmy Nilsson
- Udi Dahan
- Andres Aguiar
- Mats Helender
- Yves Reynhout
Where exactly do I fall in the voting? While I'm still trying to figure it out for sure, I think I fall somewhere in the middle. On the one hand I like having behavior on my entity objects. When I need to save a Customer I like being able to do customer.Save(). When I need to give an employee a raise I like employee.Raise(.50). With that said I think I'm slowly moving toward a Manager model, here's why:
- Certain business actions need to go through a manager. To stay consistent using a manager for everything may make more sense.
- Managers allow you to separate the business logic from the entities. This allows you to apply different business rules depending on the operation.
- Managers allow you to apply aspects easier. Introducing logic to apply aspects within my entity objects is not something I'm comfortable with.
- Business processes that involve many different entities make more sense in a manager then in your entity objects. Coupling is bad, right?
- It's more in line with SOA, after all a manager model could also be called a service model.
What's your vote?
Jimmy Nilsson's has released part 7 in his series of articles called "A pure object-oriented domain model by a db-guy". In the beta version of the article Jimmy talks about the architecture he's developed over the course of the last year or so (can't remember when I started reading his first article). Anyway, the framework that he's developed sounds interesting, I'll be very interested to check it out when he releases the code!
I've just spent about an hour messing with IIS in an attempt to get all requests to be mapped to ASP.NET. In order to get the app I'm working on running properly I need everything to go through an IHttpHandler. For some reason when I map .* on my virtual directory to ASP.NET, all I get (even for .aspx files that exist) is a “This page cannot be found error.” If I go back into IIS and remove the .* mapping the .aspx pages come back fine. If I make the same change to the root website on my local machine and browse around localhost things appear to work as expected (“The resource cannot be found error“ from ASP.NET for non-existant files/directories). Anyone have any insight?
In response to my We have OR Mappers, now with SOA we need OM Mappers Frans presents a question that should be asked before deciding whether we need an O/M Mapper. In SOA should we use the Domain Model or the Manager Model? I won't go into the specifics of each since Frans has already done so. What I will say is this... Why not both?
I don't believe we can say that in SOA we don't need an O/M Mapper because we can just ditch the Domain Model and hop on board the Manager Model. I have a bunch of applications written using the domain model. I'd venture to guess that I'm not alone. I'm not going to go and convert them all to the Manager model just so I can use them in my SOA, am I?
The question of whether I should move to the Manager Model to help transition to SOA is something I've been putting a lot of thought into recently. Whatever decision I make I'm hopefully that we can have the best of both worlds. Don't make me choose one over the other just so I can do SOA. Make it so SOA can work, and work well, with either model. Give me choice, give me options, let me keep my domain model if I want!
Over the past several months there has been a lot of discussion surrounding O/R Mappers. I've added my thoughts at various times as can be seen in the following posts:
Overall I think the community is beginning to see the value of an O/R Mapper. There are certainly many people who still won't use one and don't see the value, which I certainly don't have a problem with.
Over the course of the last several weeks I've been contemplating the way SOA will affect the way I write applications. I've been challenged by a number of people on the way I've been approaching SOA (much appreciated!) and many have pointed out that OO and O/R Mappers just don't fit in with SOA because messages in our service oriented world don't map to our objects.
It seems to be that SOA introduces another aspect into the development of our applications. We currently struggle with how our objects are mapped to our data stores. With ObjectSpaces, EntityBroker, LLBLGen, and WilsonORMapper we have some answers to how we can reduce the headache that comes with mapping our objects to our relational data store. As I see it we have two options. We can either change the way we write applications, ditch our O/R Mappers, and start anew OR we can continue developing our applications in a similar fashion utilizing our O/R Mappers, rich object model, while also introducing a new OM (object message) Mapper.
A OM Mapper would take a approach very similar to what currently happens in the O/R Mapper space. Rather then mapping our objects onto a database, our objects would be mapped onto a message. This would allow us to work the way we currently work, in our nice OO world. Our O/R Mapper would sit behind our objects and help with the persistence of our objects, and our O/M Mapper would sit in front of our objects and allow them to be transformed into the messages that our services layer uses to communicate with the outside world.
I think I might have fallen off my rocker a bit with this thought, however, at this moment in time it seems like a valid concept. Why do we have to change the way we do everything? Perhaps I'm too attached to the way I write my applications. Perhaps I need to take on a nice sized SOA project and see the ease at which it allows me to adapt. Perhaps I need to stop trying to figure out ways to get my objects with behavior into the services world. Perhaps not?
Over the past several months there has been a lot of discussion surrounding O/R Mappers. I've added my thoughts at various times as can be seen in the following posts:
Overall I think the community is beginning to see the value of an O/R Mapper. There are certainly many people who still won't use one and don't see the value, which I certainly don't have a problem with.
Over the course of the last several weeks I've been contemplating the way SOA will affect the way I write applications. I've been challenged by a number of people on the way I've been approaching SOA (much appreciated!) and many have pointed out that OO and O/R Mappers just don't fit in with SOA because messages in our service oriented world don't map to our objects.
It seems to be that SOA introduces another aspect into the development of our applications. We currently struggle with how our objects are mapped to our data stores. With ObjectSpaces, EntityBroker, LLBLGen, and WilsonORMapper we have some answers to how we can reduce the headache that comes with mapping our objects to our relational data store. As I see it we have two options. We can either change the way we write applications, ditch our O/R Mappers, and start anew OR we can continue developing our applications in a similar fashion utilizing our O/R Mappers, rich object model, while also introducing a new OM (object message) Mapper.
A OM Mapper would take a approach very similar to what currently happens in the O/R Mapper space. Rather then mapping our objects onto a database, our objects would be mapped onto a message. This would allow us to work the way we currently work, in our nice OO world. Our O/R Mapper would sit behind our objects and help with the persistence of our objects, and our O/M Mapper would sit in front of our objects and allow them to be transformed into the messages that our services layer uses to communicate with the outside world.
I think I might have fallen off my rocker a bit with this thought, however, at this moment in time it seems like a valid concept. Why do we have to change the way we do everything? Perhaps I'm too attached to the way I write my applications. Perhaps I need to take on a nice sized SOA project and see the ease at which it allows me to adapt. Perhaps I need to stop trying to figure out ways to get my objects with behavior into the services world. Perhaps not?
If your aspiring, or already are a manager you better check out Geoff Oliphant's Two Minute Management Lesson:
A turkey was chatting with a bull.
"I would love to be able to get to the top of that tree," sighed the turkey, "but I haven't got the energy".
"Well, why don't you nibble on some of my droppings?" replied the bull. "They're packed with nutrients."
The turkey pecked at a lump of dung, found it actually gave him enough strength to reach the lowest branch
of the tree. The next day, after eating some more dung, he reached the second branch. Finally after a fourth night,
he was proudly perched at the top of the tree.
Soon he was promptly spotted by a farmer, who shot the turkey out of the tree.
Management Lesson:
Bull Shit might get you to the top, but it won't keep you there.
One of the core tenants of a service oriented architecture is messages. Within SOA everything is passed around using messages. By wrapping requests and responses in messages we gain the ability to extend our architecture. Over the past couple months I've seen the value of “messages” within an OO application I've been working on. Now although they're not really messages they do taken on a similar role. Within the application I've mentioned the user can perform various searches using a broad range of criteria. What began as this:
public MyCollection Search(string criteriaOne, string criteriaTwo);
was quickly becoming:
public MyCollection Search(string criteriaOne, string criteriaTwo, string CriteriaThree, string CriteriaFour, ...);
Since the different criteria could be mixed and matched we also had a decent number of overloads. Rather then continuing the madness we altered the method signature to allow us to add additional criteria in a simpler fashion.
public MyCollection Search(Criteria criteria);
Now when a new search criteria is added we simply update the Criteria object and ensure that the value is used in the query when its provided. It's proved to be a lot easier to maintain and is a lot cleaner. By wrapping the criteria up into a “message” we were able to allow the Search functionality to be extended in a much simpler fashion.
Yesterday morning I was working on implementing a spell check into an application that I've been working on for the past couple of months. After getting a working prototype together in the morning I headed out to a sales call for a potential client. This morning I sat back down at my desk expecting to pick up right where I left off. I started coding some additional features, opened up my browser, and tested things out. Ok, that didn't work. Let me back up for a second. Undo. Undo. Undo. Still not working. Huh? I know this thing was working yesterday. Its been one of those days. Everything that should work just isn't. Somebody flipped the “change the way you expect everything to work” switch on me this morning and I haven't been able to figure out where it is to flip it back. HELP!
I commonly hear the following from people just getting familiar with Agile methodologies:
- “You just want me to start coding, shouldn't I plan things out first?!?!”
- “No documentation, woohooo! But, won't the client want some?”
The Agile Business Coach explains that we don't choose one principle instead of another, we choose it over another.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Last week we had Compuware come in to give the tech group a demonstration of their DevPartner product. Today I came across a thread on the DevelopMentor mailing lists regarding this same topic. What tools are you using to profile .NET apps?
I've just came across a community of
ThoughtWorks bloggers. Subscribed.
Today I've uncovered a new security method for securing sensitive areas of a website. While working on the redesign of a website one of my buddies uncovered an administration section for the website. The admin allows the client to update various sections of their website. Rather then bothering with the overly complex username/password to secure the site the developers who originally developed the site decided to go this route:
* UNAUTHORIZED ACCESS PROHIBITED *
There we go...that should do it. Now if anyone happens to come across the admin they are sure to immediately leave. Forget the username and password, just provide a simple message letting everyone who isn't authorized know that they are not allowed to use the admin. Why didn't I think of that!
In response to my “Are object with behavior bad for SOA?” post Sebastien brings up a couple interesting points. He argues that the debate isn't worth having since you pass messages around in SOA not objects. Although in theory he's right, I'd argue that you are passing objects, they're just wrapped up in messages. Heck, the argument could even be made that the messages being passed are objects. Regardless I think whether he wanted to or not he validated my point. It absolutely doesn't matter if your objects have behavior or not. The client code that's using your service will only see your objects as they've been defined within the WSDL/schema for the services.
UPDATE: See some follow up comments on Sebastian's blog. I agree with what he has to say. Assuming messages always map to objects is somewhat limited, and as he pointed out there are plenty of examples of how and why this view could cause problems.