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 pass up an opportunity to get additional insights from my peers I added him to my contact list so I could drop him a follow up email.
Udi offered some interesting insights that we both thought others might be able to benefit from. His thoughts are included below:
The sales team, unless they themselves are HIGHLY technical, can't land large tech jobs by definition. Consider yourself as a client looking for someone to do a large project for you. Chances are this project is important, and you'd only give it to someone you know and trust. Now, even if your manager is the one who ultimately decides which company is going to do the project, you probably have a large say as to who it is. So, you probably wouldn't be impressed by some sales person.
The direction I think you should take is this. Among the clients you already have, develop strong relationships with people in senior IT positions. These are the people who influence which projects go to which company. Don't send sales people. Build a rapport between your technical team, and your client's technical team. When the time comes around for one of your existing clients to look for a company to do a large project, 1. chances are you already know about it; 2. you intimately understand the need allowing you to ...; 3. make a very good proposal which will doubtless get the approval of your client's senior IT staff and ...; 4. get you the project.
Once you have a number of large projects under your belt, I think that you'd agree with me when I say that the way forward is much clearer.
What's nice about this approach is that it doesn't cost marketing dollars, but rather an investment in time - on which it may be easier to get management to sign off. Also, it good business practice to leverage existing customers by deepening your relationships with them.
I think Udi hits on a very important point. A sales guy isn't going to go in and land large technical projects. A salesman can't give the client the sense of comfort and trust they need. The client needs to get to know our technical staff. We need to share our expertise with them, and help them see that we know what we're doing. No matter how good of a pitch the sales team puts together its really going to come down to having the client believe in the people who will actually build their solution.
Can a “sales guy” go in and sell a client on a large technical project? What type of person does it take? How are you getting your clients to believe in you?
A couple weeks ago I made the bold statement that SOA was *just* interface based programming with web services. I have a little secret which I think its time to let out of the bag. I don't really think SOA is interface based programming with a little bit of web services thrown in .
Service Oriented Architecture is a new way of architecting applications. It really doesn't have anything to do with interfaces, objects, or anything else we think about in our programming box. SOA is about architecture. Its about how we put together the pieces of our application. SOA is about decoupling our objects from the actions and services we need to perform against them.
If we use SOA to architect our application that doesn't mean we no longer use objects. It just means that our objects are data containers created from a schema. The schema defines the objects so that other platforms (Java and friends) can also work with our data. The schema allows us to pass the object (with its data) across the wire to services living on the other side of the world. These services may be Java, they may be .NET, who knows, and who cares. By defining our contract using schema's we remove the platform from the information required by the service. As long as the service agrees to work with objects matching the schema which they agreed to everyone is happy.
SOA does give us some of the same advantages that interface based programming gives us in the OO world. After all our services are agreeing to a contract. By forcing our services to agree to a contact we introduce the ability to plug in any service we want as long as they agree to our contact. This is similar to the OO idea of defining interfaces on objects so that we can “inject” new implementations by creating a new class that implements the given interface. What we don't get in the OO world from interfaces is the ability to extend our custom classes. Since the extension can't be defined in the current interface we need to create a new interface for any extensions. In an SOA world we can extend our contract. By defining a xsd:any element in our schema we open up the ability to extend the service without creating a new contract. This is goodness.
Another advantage we get from SOA is the ability to introduce aspects into our design. Although this is possible in the OO world it isn't quite as easy as when we're using services. The service locater within your application can be enhanced to allow aspects to be added to the design rather easily. Within the configuration file for the application you will not only define what service end points to use but also additional information regarding the aspects you want used with your services.
SOA and interface based programming share the advantages that are gained from a common contact. To say SOA is just interface based programming misses many of the reasons behind SOA. It overlooks the ability to distribute services across servers, the ability to plug-in new services, the ability to extend the contact on a needed basis. There is much more to SOA then just interfaces and contracts. I've only begun to think about the implications that SOA will have on the way I design the large .NET applications that Scoble helps me find.
Agile development offers many advantages during the build of an applications. By following the Principles of Agile Software, I strongly believe that development teams as well as the clients they're working with can see significant benefits. Since the benefits are already well documented, I'm going to assume that you all buy into this thought.
As you can tell by my previous post I've been thinking a good deal recently about how to sell larger technical projects. I'm specifically interested in large .NET jobs if you can believe that !
Can the principles of agile software help sell larger technical jobs to clients? I think so. One of the problems I often see in the sales cycle lies in the fact that our prospective clients can't *really* trust us. We can instill some trust by telling them about our past successes, and by showing them some examples of our work, however, I don't think that gets us far enough. They need more then a couple of pretty pictures and a nice story. We need to reduce their risk. We need to gain their trust. We need to show them that we are experts. We need them to see that we understand their problems, and even better we know how to develop solutions that can fix their problems.
How does agile help us? Agile projects focus on short iterations. After each iteration we deliver a working piece of software. Following the iteration the client has a couple of different options. They can tell us to get working on the next iteration, they can change the focus of our development efforts, or they can terminate the development all together. When I look at this from a clients point of view this sounds pretty darn good. I get to see what kind of work we do, with only a couple weeks investment. I don't have to hand over a big lump of money and hope that in the end I get what I want. I get to see the direction the project is going every couple weeks. I get to be involved, I can actually change my mind without dealing with change order, as a client I like what I get out of agile. I think agile can make selling large technical jobs easier.
What do you think?
I'm on a mission. My mission is to help my employer land some big .NET jobs. Maybe not as big as: .NEAT and Thomson ONE: Smart Services for the Next Generation, but big. My mission is very selfish. Over the past six or so months I've been doing some .NET development, but it hasn't been on a large project. I need a big .NET project! I need something interesting, challenging, and exciting. I need a .NET job that I can really wrap my head around.
So the question becomes....how? What does it take to land a big .NET job?
- Expertise - We need to be seen by our prospective clients and the general community as technical (.NET) experts.
- Position - We need to position ourselves properly. Being positioned as a design/UX shop won't work, we need to be positioned as a technology company.
- Identify opportunities - We need to be able to identify the problems that our clients have. After identifying their problems we need to sell them on our solutions.
- Deliver - After selling our clients on our solutions we need to deliver. Our delivery has to let our clients know that we are experts. We need them to think of us, as soon as they start seeing problems or inefficiencies in their processes and systems. We need to be the place they turn when the “next“ big job comes along.
What else does it take? How are you, and your employer, selling clients on large .NET jobs? What do you think I need to do to complete my mission?
Over the last week or two I've exchanged a couple emails with Paul Wilson in regards to his WilsonORMapper. For those of you who haven't check it out yet, I'd encourage you to do so. It provides an excellent example of what a O/R Mapper does, and a peak behind the scenes of how a O/R Mapper can perform its “magic.” When I first checked out Paul's O/R Mapper I questioned how performant it would be in a production environment due to the amount of reflection that was being used. This is what prompted me to do a little investigation, and resulted in my “The cost of reflection” post. Paul's follow up posts regarding the work he did to optimize the performance of his O/R Mapper hit on a very important point. When measuring performance be sure to look at it in the context of the total application. There's a good chance that what you believe is the slow part of the application isn't actually that bad. For a perfect example of this take a look at where I stood last week. I declared that reflection on private fields was slow. In fact much slower then accessing public properties directly. From this I concluded that the amount of reflection in Paul's O/R Mapper would make his mapper perform less then optimally. Now take a look at Paul's most recent post on how he optimized his O/R Mapper. Although reflection on private fields was slow, it wasn't anywhere near the top of the list. My assumption that the reflection would slow things down was wrong. Even with reflection his mapper performed comparably to using DataSets. At least everyone now knows to ignore everything I say
UPDATE: Steve Maine posted a follow up which provides the results from some more comparable tests.
Reflection is a very powerful feature within the .NET Framework, however, it does come at a cost. A couple months ago I did some benchmarks on a class library that was taking advantage of reflection and found the impact of using the reflection fairly significant. The finding prompted me to rethink the way I was using reflection. Since I was using it to get all the properties of my class as well as check for the existence of custom attributes defined on the properties I was able to change the logic of my library to only perform the reflection process once. After gathering the information using reflection I used the CodeDOM to create a dynamic assembly to perform the task, which turned out to be a heck of a lot faster then the previous method. What I didn't benchmark was the cost of simple operations using reflection. What's the the cost of setting a property or field using reflection? Let's find out.
To determine what cost is associated with using reflection to set fields (or properties) I wrote two NUnit tests. The first test (“ReflectiveFieldSet“) sets the _myProperty field of the MyClass object 100,000 times using reflection. The second test (“NormalFieldSet“) set the _myProperty field through the “MyProperty“ property on the class.
Using the reflective approach to set the fields value 100,000 times took an average of 4.8 seconds. If the GetField was included within the loop the average time jumped to approximately 9.3 seconds. The loop that sets the value through the “MyProperty“ property takes only 0.01 seconds. As you can see, the impacts of using reflection even for simple field sets can be pretty costly. With that said, keep in mind that for a lot of applications the cost of reflection will have little to no impact on the overall performance and usability of the application.
int REPS = 100000;
FieldInfo field = typeof(MyClass).GetField("_myProperty", BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public);
[Test]
public void ReflectiveFieldSet() {
MyClass my = new MyClass();
for(int i = 0; i < REPS; i++) {
field.SetValue(my, "steve");
}
}
[Test]
public void NormalFieldSet() {
MyClass my = new MyClass();
for(int i = 0; i < REPS; i++) {
my.MyProperty = "steve";
}
}
public
class MyClass {
string _myProperty;
public MyClass(){}
public virtual string MyProperty {
get { return _myProperty;}
set { _myProperty = value;}
}
}
Paul Wilson asks the all important question. Should an O/R Mapper use attributes or a mapping file?
I've always leaned toward attributes for mapping objects to the database. I liked having my mappings defined right there with my class. Most of the time when doing development if I'm changing the name of a column I'm also changing the name of the associated property, so having the mappings right there in the class wasn't too much of a problem.
Recently I've found myself being drawn to the external mapping file. I still don't like the fact that its yet another thing for me to manage, however, it has obvious benefits. By taking things out of the class you reduce the coupling between the class and its mappings. The mappings get totally separated, and allow them to be updated without recompiling. As I've mentioned in previous posts I also have a set of custom attributes that define validation rules for my classes. The arguments that Paul makes for O/R Mappings in external mapping files also applies to validation rules. Having everything in an external file allows things to be updated “on the fly,“ and removes the need to recompile and redeploy.
So, although I currently use custom attributes to handle my mappings, I think I like the route Paul has taken better. You live and learn.
Steve Maine responds to my question:
Do Xml web services make SOA better or more interesting then normal old interface based programming in an OO world?
I vote that the answer to this question is an emphatic “absolutely.”
Brian Vargas disagrees with Steve Maine but agrees with me when he says Services Really *Are* All About Interfaces.
What do you think?
Jesse Ezell brought up some very good points in response to my Isn't SOA just interface based programming post.
At the heart of the discussions surrounding why to move to SOA are points which sound just like the arguments I've heard for using interface based programming in the OO world. I'll change my previous statement about SOA to a more focused “major generalization“:
SOA is just interface based programming for web services.
By combining the advantages gained by interfaces as well as the advantages gained by web services you get the advantages gained by SOA. Although SOA works a little bit differently (messages instead of objects) it really isn't *that* much different. After all can't a message be considered a type of object?
Although I agree with Jesse when he says “The 'plug-and-play' aspects of web services are a non-factor in most of today's SOA implementations“, I don't think just because today its a non-factor, that in general its a non factor. Extensibility is a major selling point for any application or architecture. The ability to swap services in and out is a big deal in my book.
I agree with Jesse that SOA and interface programming are very different on the surface. However, I will maintain my stance that SOA isn't as different as all the hype would have you believe. Think about all the goodness that interface programming brings to the OO world. Now think about all the goodness that web services can bring. Throw them both in a bowl, mix them all up (which will give you SOA) and tell me whats new? Just the hype.
I've been reading a lot of SOA posts lately from James Avery, Udi Dahan, Steve Maine, Clemens Vasters, and several others. Is it just me or is SOA just hyped up interface based programming?
In OO systems we often declare interfaces that define the behavior of our objects. These interfaces allow us to plug in new implementations quickly and easily. By coupling our objects to interface contracts rather then concrete objects, we reduce the coupling between our objects. Is this different then SOA? Do Xml web services make SOA better or more interesting then normal old interface based programming in an OO world?
Am I missing something? Does the fact that the object implementing the interface lives behind a web service make it that much more revolutionary?
Within a current class library I've developed a validation component that uses custom attributes. By decorating properties of my classes with the “validation attributes” I can have the library automatigically create validators for my classes. The below is an example of a class that makes use of the auto validation component:
public class Customer : IAutoValidated {
[Required]
public string Name {
get {...} set {...}
}
[MaxLength(50)]
public string MyNotTooLongString {
get {...} set {...}
}
}
When the above customer objects is saved the validation component will use the Required, and MaxLength attributes to validate the object. If the Name property is not set or if the MyNotTooLongString is greater then 50 characters a ValidationException will be thrown. The validation component uses reflection to do some of its work. Since reflection is generally not the speediest process I've decided to use a marker interface to tell my class library which components should be auto-validated. This will prevent the framework from trying to create validators for objects which don't need them. Within the code that saves an object I only call the validation if the object implements the IAutoValidated interface.
if(anEntity is IAutoValidated)
Validate(anEntity);
I'm using the IAutoValidated interface as a marker. If the object implements the interface I know that it wants to use the auto validation, if it doesn't implement the interface I know I shouldn't do the extra work that is required to “create” the validator.
Do you use marker interfaces? Why? Why not?
Over the past year I have looked at a large number of .NET O/R Mappers, hoping to find something that I really liked This afternoon I read Jan Tielens Getting Started with ObjectSpaces article on MSDN. I had high hopes for ObjectSpaces. While there are a lot of things within ObjectSpaces that I do like, my overall feeling isn't too good.
Here are the things which I do like:
- An ObjectSpaces object doesn't look any different then any other object. I'm not forced into inheriting from a base “ObjectSpacesObject“, and I don't have to decorate the properties of my object with an ObjectSpaces attributes for the mapping.
- In theory I like the concept behind OPath. When your working with objects you should be able to query them using something that makes sense for objects.
- A mapping tool that is integrated withing VS.NET. Although it isn't currently integrated Jan says that it will be by the time the beta rolls around. I definitely want to stay within VS.NET so this is a plus.
- The ability to create compiled ObjectExpressions for querying objects. http://longhorn.msdn.microsoft.com/lhsdk/ndp/daconusingobjectexpression.aspx
And now the things I don't like:
- It only supports SQL Server. I want a O/R Mapper that can support whatever I want. I want built in Sql Server and Xml support, and I want to be able to create whatever other support I need by creating my own custom ObjectProviders. I want to plug in new providers through some simple configuration.
- It makes working with objects messy. I have to do all sorts of ObjectSpaces “stuff“ that I don't want to. Lets look at how I would go about saving an object as an example:
First I need to create a SqlConnection, and hook up my connection to the ObjectSpace. Next I change the properties of the object. Finally I tell my ObjectSpace that I want it to track changes to the object, and then persist.
SqlConnection conn = new SqlConnection("Data Source=localhost;Integrated Security=SSPI;");
ObjectSpace os = new ObjectSpace(@"C:\ObjectSpacesDemo\ObjectSpacesDemo.msd.xml", conn);
Data.Customer c = new ObjectSpacesDemo.Data.Customer();
c.Name = “Steve Eichert“;
// set other props
os.StartTracking(c, System.Data.ObjectSpaces.InitialState.Inserted);
os.PersistChanges(c);
Yuck! I'd prefer this instead:
Customer c = new Customer();
c.Name = “Steve Eichert”;
// set other props
c.Save();
And then their's deleting data:
SqlConnection conn = new SqlConnection("Data Source=localhost;Integrated Security=SSPI;");
ObjectSpace os = new ObjectSpace(@"C:\ObjectSpacesDemo\ObjectSpacesDemo.msd.xml", conn);
Data.Customer c =
(Data.Customer)os.GetObject(typeof(Data.Customer),
"Name = '" + textBox2.Text + "'");
os.MarkForDeletion(c);
os.PersistChanges(c);
instead of something like this:
Customer c = new Customer().GetByName(textBox2.Text);
c.Delete();
Now I'm sure anyone who uses ObjectSpaces will write wrappers to reduce the amount of code necessary for working with ObjectSpaces objects, but, should they have to? Wouldn't it be nice if it was designed so that we didn't have to do a bunch of setup, wouldn't it be nice if it was transparent?
At this point I've only taken a high level look at ObjectSpaces. There is a lot that I like, but, also some things that I don't like. What I really want is an O/R Mapper that is transparent. It sits there in the background doing all the work, without me really knowing or caring. I don't like having to go through all these broker, context, and objectSpace objects to save, retrieve, and remove my objects.
One of the common questions people ask me when I tell them some of the side projects I'm working on is “Why not just use X instead of writing your own.” There certainly is a time when it does make sense to buy and existing peice of software, however, there is also a lot that can be gained by writing your own solution. I think Don Box does a good job of summarizing why building your own solution is *sometimes* the way to go.
To answer the obvious "why don't you just use {insert-existing-software-here}" question the answer is easy: leverage. By building my own engine (again), I get to have some experiences (and hopefully insights) I might not otherwise have if I just configured MT, dasBlog, or dotText. I also expect to have a smaller code base and can hopefully morph the engine more rapidly as I go along - I have a lot of ideas I want to try out and I lose that opportunity just installing some software.
http://www.gotdotnet.com/team/dbox/default.aspx?key=2004-01-01T11:26:43Z