January 2004 - Posts
I'm sitting here watching the .NET Show with Don Box and Chris Anderson and noticed that they're wiring up their event handlers in the XAML, not within the code behind. This reminded me of the age old debate that we're faced with in todays .NET 1.1 world. Do you wire up your event handlers in your ASP.NET page or within the code behind for the page?
My personal preference is to wire everything up in the code behind. Since I'm declaring all my objects there, as well as writing all my handlers within the code behind it feels more natural to also wire up my handlers within there. A couple of my colleagues prefer to wire things up in their ASP.NET pages since the VS.NET designer is less likely to wipe those out when switching between HTML and design view.
Where do you wire up your event handlers? Why do you think your way is the "right" way?
1) Do you get all your contract opps through recruiters?
2) If you answered Yes to #1, Why? Is it too hard to find the opportunities otherwise?
3) Does anyone have their own business and do stricly "contract work" through it? If so how do you find the contracts, and how is it different then when you get the gigs through recruiters? If you do the gig through your own company is their anything special you need to do? Any special insurance or etc that you need to do that the recruiting agency would normally do?
4) What's the insurance "market" look like these days for a contractor? What different options are available?
5) What do you like about being a contractor?
6) What do you not like?
Thoughts and opinions are greatly apprecaited!
I've recently noticed that I'm a little overzealous when it comes to trying to reduce the number of hits to the database in my applications. This overzealousness has been known to cause sections of my applications to be more difficult to code, or have a less usable API. Back in my grand old "classic" ASP days it was pretty easy to keep the interactions with the database pretty low. After all we weren't really separating responsibility, using objects, or doing anything other then procedural programming. Since everything was procedural it made it pretty easy to open up a connection at the top of the page, run a proc that collected all the data that was necessary for the display of the page, and then loop through the records in each of the returned recordsets.
When we start separating our logic out into classes, and applying the Single Responsibility Principle (when we can) to our objects, we start to introduce designs that *can* cause our application to be more chatty with the database. On my current project I've realized that my stinginess with database calls has influenced how I've designed portions of the application. The question now becomes is it worth it? Do we save "more" by increasing performance, or by creating our object models without worrying about a couple extra hits to the database? Could a more usable API warrant the cost of a couple extra database hits? How much is the usability worth? How much is the performance worth? How much does the usability cost? How much does the performance cost?
What's worth more?
Yesterday I posted about the custom tool I've been playing with recently. The goal is to make updating schema's and stored procedures effortless. When a class is saved (which has the custom tool assigned to it), the custom tool will read in the details of the file and re-generate the associated table, as well as the stored procedures it uses to perform CRUD operations.
How am I accomplishing this mighty feat? Well, actually I'm not...I just have the part down where the tool runs and I can get the details about the class that was saved. The first step in the creation of my custom tool was following the set of instructions from Drew Noakes post Writing a custom tool to generate code for Visual Studio .NET. To help in the process of registering my custom tool I created a .reg and batch file. The batch file handles creating the table library export with tlbexp, running regasm to register the .dll with COM, and adding the necessary registry entries.
setup.bat
tlbexp SqlGenTool.dll
regasm /codebase SqlGenTool.dll
regedit /s SqlProcGen.reg
pause
SqlProcGen.reg
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Generators\{FAE04EC1-301F-11D3-BF4B-00C04F79EFBC}\SqlProcGen]
"CLSID"="{CE29F10F-8594-40fa-9633-32E839B345C3}"
"GeneratesDesignTimeSource"=dword:00000000
@="Sql proc generator for EF"
After creating a simple add-in to show a message box, I ran the above batch file, and launched another instance of VS.NET. I created a new class file, and added SqlProcGen as the custom tool in the properties for the file. Now for the almighty test run. CTRL+S.........WOHOOOOO....a beautiful "Hello" message pops up.
Now that I had the custom tool setup I was pretty stoked. I actually know how to follow directions, amazing! Thanks go out to Drew for his excellent instructions.
Ok, big deal I got a custom tool setup, now the REAL work begins. How can I get all the details about the class that I need to generate my DDL for? When the file is saved the file path as well as the contents of the file are sent over to the GenerateCode() method in my custom tool. Rather then spend hours thinking about all the ways to accomplish this I went with my first thought which involved using CodeDOM to compile the class. If I can successfully compile the class I can then reflect on it to find all the details I need.
After a bit of hacking I was able to get the code passed into my custom tool to compile. Since the class uses my entity framework I needed to reference the .dll for the framework when compiling the class in my custom tool. I tried all sorts of craziness to get the reference setup but it seems that no matter what, it looks for the assembly in the {VS.NET Path}/Common7/IDE/* directories, specifically PublicAssemblies and PrivateAssemblies. What seems strange is that the CodeDOM doesn't seem to pay attention to the path I give it for the assembly when I add it to the CompileParameters.ReferencedAssemblies collection. In order to finish my proof of concept, I just copied my framework .dll to the PublicAssemblies directory. After re-compiling my tool (and restarting VS.NET) I was able prove that I could indeed compile the saved class in my custom tool. I can now reflect on the compiled class to get all the goodies I need to generate the schema, and procs for my objects.
Overall, the creation of my custom tool was pretty straight forward. I'm still left with a couple questions.
- Why doesn't the CodeDOM pay attention to the path I provided it for my referenced assemblies.
- How can I get my custom tool to use the same framework .dll used by the project during the compilation of the saved class?
- How can I write a custom tool without restarting VS.NET every two seconds. (When VS.NET loads it seems to lock the custom tools .dll and doesn't let go of it unless you shut down all instances).
Over the last couple of weeks I've been working on a couple projects that use my Entity Framework. I've noticed that I spend a good bit of time updating my entities and then also updating the stored procedures that are used to save, retrieve, and delete the entities from the database. Usually its a pretty straightforward process:
- Add a field to my entity object
- Add a field to my database
- Add a parameter to my stored procedures
I realize I could get around this "problem" by having my framework use a dynamic sql provider rather then the stored procedure based provider its currently using. This isn't an option for the particular app I'm working on for various reasons that I'm not going to get into now. What I've been thinking about recently is how I could automate the process listed above. A couple weeks ago I was taking NEO for a test run and noticed the nifty tool they use to generate their entities. Basically all the definitions for the entities are defined in an xml schema file. When the schema is saved, through a magical wave of the hand, a C# code file is created with all the entities. The tool basically works just like the DataSet generator does with xsd's.
On to my thought. Yes, believe it or not I actually have these from time to time.
What if when I saved my entity object I got a nice little prompt asking me if I wanted to re-create my TABLEs and Stored Procedures. The prompt would take some connection info (which would be cached after the first time it was entered) and perform all the goodness necessary for my TABLE's and PROCS to get in sync. Since there would undoubtedly be times when I didn't want this to happen, there would have to be a way to exclude a file from being part of the wonderous auto update madness. For instance, when I write a really nasty proc with all sorts of stuff you just shouldn't do in a proc, I wouldn't want my auto updating to just wipe it all away.
This afternoon I wiped up a little proof of concept which leads me to believe I can do what I want. I still need to figure out how to tell VS.NET that it shouldn't actually create a file when my tool runs, and also how I can work on a custom tool project without having to close down VS.NET every other second to get VS.NET to release the reference to my COM-Interoped object. So, if this works how I want it to it could be super duper sweet...of course it could also be a total failure. Such is life...
My Reference for creating my custom tool:
http://drewnoakes.com/snippets/WritingACustomCodeGeneratorToolForVisualStudio/
Friday afternoon things where a little light here at work so I picked up a copy of Microsoft Content Management Server and started installing it. We're currently evaluating several Content Management products and as part of the process doing "technical briefs." The briefs overview the features and functionality, provide pros and cons, and provide an overall summary of the product and when it might be a good canidate for use on our projects.
Despite the terrible UI of the sample site, I actually really like the product. It provides a lot of really nice functionality and makes developing sites pretty simple. I re-did our company website (with most functionality) in a little under 6 hours.
Overall a very nice app...now the price tag is a different story 
What is your CMS of choice?
Steve Maine does a very nice job explaining
why XSD is not a type system. He does a much better job explaining the differences between types and schema's then I did in some of my previous posts. So, if you read my "
Share schema not type" or "
I'm not sharing schema just because Don Box tells me too" posts and were left somewhat confused regarding the difference between types and schema check out Steve's
post.
Does anyone have any recommendations for a search component. We need it to have support for searching files as well as dynamic data stored within a database. Has anyone used either dtSearch or Atomz Search?
On the eCommerce side I've found a couple:
Anyone care to share any experiences? Or better yet recommendations? I've already check all the usual spots for recommendations and haven't uncovered much 
Today we had a tech lead meeting and discussed what the appropriate amount of detail is when working on a project. The discussion was based on a "debate" we had in our technology department meeting last week. In the meeting we talked about whether a very detailed project plan, with milestones, leveled resources, and dependencies is better then a more relaxed plan where those on the project are told what needs to be done for the week, and when they need to be done.
Overall it seemed that most of the group preferred a more relaxed plan over a highly detailed plan. By having a more relaxed plan they felt they were better able to adapt to changes. We also had several people who were strongly in favor of a very detailed project plan, that is kept up to date throughout the project. I'm not sure exactly where I fall. I think a detailed plan can be helpful, but I also like the flexibility that the "relaxed plan" provides. The other thing that I really like about the more relaxed plan is that it really places the focus on the people on the project. Since they don't have a super detailed project plan to look at they are more likely to get up and communicate with the other members of the team. As a believer in Agile development I believe in the "People over processes" principle. If we get to tied up in managing the plan and ensuring its 100% accurate we can forget about the most important peice of the puzzle. If the members of the team aren't communicating, aren't working together, and aren't given the trust they deserve, then the team will inevitably run into problems.
What do you prefer? Do you prefer to have a detailed project plan that outlines each and every task that you need to do every day or do you prefer a more relaxed plan that gives you the high level deliverables that your responsible for? Or something in between?
After reading my previous Share schema not type post I realized I didn't really explain why we share schema and not type. After all will anyone blindly start sharing schema and not type just because Don Box says thats what he wants you to do? Ok, your right, you probably will, but hey lets pretend for a second that he doesn't have his secret spell cast over you 
.
Why do we want to share schema and not type? In my previous post I mentioned that one of the reasons is that by sharing schema we get the advantage of being able to make our services platform independent. After all a schema is just Xml, and every platform around can figure out how to use a beautiful blob of Xml if it has a schema attached to it. Is platform neutrality the only reason to share schema instead of type?
In the past we've always shared our types so whats the big deal? In many of our applications we create a base class library that contains all or our types. The types represent the entities within our business. Often times we share the types within our base library with a ASP.NET web applications, a WinForms app, as well as with our Windows Service. So why can't we just share our types with the consumers of our services?
- Platform - As mentioned above, we can't give a Java zealot our .NET assembly containing our types and expect it to be of any use. He needs to be able to use our service in his Java app. Telling him to just use the VS.NET conversion wizard to move his project to J# unfortunately isn't a valid counter-argument. He needs to know the schema for our entities, our types do him zero good.
- Extensibility - If we share our types we don't have the ability to extend the information that is passed along between the applications end points. If we need to add a new field we need to recompile and redistribute our types. If the data within our type doesn't provide everything that everyone needs they don't have the ability to tack on extra information without breaking things. By sharing schema's and not types we get the ability to extend the entity anywhere in the pipeline. If we add additional fields in the future, assuming we planned for this accordingly, we can update our service and not break clients using the service. xsd:any is the secret behind the extensibility.
- Fragility - Sharing types makes our services fragile. We're asking for something to get out of sync and go BOOM.
- Maintenance - If we share types instead of schema we introduce a whole slew of maintenance issues. Whenever our types change we have to deploy and update clients using these types. It just isn't pretty.
I'm sure there are many more reasons to share schema and not type, however, I'm starving and need to go get some grub! While I'm gone add everything I'm missing to the comments of this post
UPDATE: Here's a link that provides some additional insight on reasons to share schema not type.
Recently I've posted a fair amount about service oriented architecture (SOA). Today I'm going to share some thoughts on one of the most common things I hear when people talk about services and SOA.
“Share schema not type!”
Ok, sounds good! But what exactly does this mean? Most of us are used to working in a world of types. When we build our applications we create a set of classes to model the entities that are involved. These entities are defined as classes in our C# or VB.NET projects. If we're writing an eCommerce application we might have Order, OrderItem, Product, and Customer classes. We create these classes using our programming language of choice. After we build the classes we compile our project and wala, we have types. As we code up the business logic of our application we use these types to perform all kinds of super exciting work for us. We add products to an order, apply a discount to the order total, and have a penny of each order go to our secret retirement fund !
In a service oriented world we need to represent the same entities. However, we don't want to do it using types. Instead we want to define the entities using schema's. Instead of sharing the assembly (.dll) which contains all of our types we share a schema (.xsd). By sharing the schema instead of types we get the wonderful advantage of platform independence. We can be in .NET, the consumers of the service can be in Java. As long as we are sharing the same schema we are all living the good life.
The nice thing about “web services” is that we don't have to explicitly send the schema to the people that use our services. We share our schema with the world through our WSDL. Our WSDL not only allows us to share our schema but it also defines all the wonderful things that consumers of our service can do. If you haven't already, go Learn to love WSDL!
This all sounds simple enough, so why do a lot of the people I talk to about services not get the “share schema not type“ mantra? I think a lot of the confusion is due to all the magic that .NET and Visual Studio perform. If your coding your services using VS.NET chances are it *feels* an awful lot like your sharing types, not schema. Let's look at a brief example. Let's pretend we're creating a TimeTracking service. The service should allow us to get a list of active projects that we can bill our time too. We'll most likely have a simple type defined as such:
public class Project {
public string ProjectName;
}
Now, our .asmx will likely have a method that goes out and gets the list of projects and returns them to the user.
[WebMethod]
public Project[] GetProjects() {
// perform magic to get projects from wherever they're stored (Db, Xml, config file, etc).
Project[] projects = DoMySuperSecretCoolProjectRetrieval();
return projects;
}
Ok, that looks pretty good. But aren't we using types? We're returning an array of projects which most certainly means we're sharing our Project type, right? Well not exactly. VS.NET makes it so we don't even realize we're sharing schema. When we compile our ASP.NET Web Service VS.NET automagically creates a schema for our Project type. Our WSDL contains this schema in the types section (Although if you watch Scott Hanselman's
Learning to Love WSDL presentation you'll realize this might not be the best way). So...although all we work with in our web service code is types, we're not actually sharing those types, we're sharing a schema. It just so happens that we're not explicitly creating this schema ourselves.
Since VS.NET automagically creates our schema's and WSDL that means its one less thing for us to learn! If only we were so lucky! The fact that VS.NET automagically creates schema's and WSDL for our services does NOT mean that we don't have to know what its doing. If you start building real services you're not going to want to rely on VS.NET to do all the dirty work. You'll want to create your schema's yourself. You'll want to start by defining your contract (WSDL) not have it be an after thought.
So remember the services mantra....Share schema not type!
Over the last month or two I've come across a lot of interesting comments and posts from Udi Dahan. In the comments of my “How do you land large .NET jobs?” post Udi left a comment along with his email address in case I wanted to follow up. Since I never