October 2003 - Posts
The unveling of Whidbey, Yukon, Indigo, and all things Longhorn this past week has me excited about whats to come. Although I couldn't experience the PDC first hand, all the blog crazy attendees made me feel as if I was there. They did an amzing job covering many of the sessions, providing pictures, videos, and random thoughts on the overall experience.
In the “sooner” future I'm looking forward to what Whidbey will bring us. What I'm looking most forward to is:
- Refactoring in C# IDE - much needed
- ObjectSpaces - I'm a little skeptical still but am hoping to be impressed
- Generics - I can't wait to get rid of all those friggin casts
In the “distant” future I'm excited about:
- Xaml - declarative UI's just make sense
- Avalon/Aero - it just looks killer
- Indigo - I've already tried to start making the shift towards thinking in a service oriented world. I'm interested to see how the OO and SOA worlds will fit together. I'm much more on the OO side of the world currently so I'll have to try and get to the “Indigo state of mind“ before it's released.
- WinFS - A Lap Around Longhorn...Don Box and Chris Anderson are just scratching the surface but man does it look killer.
In summary I'm excited about everything I've come across 
One of the new features within ASP.NET Whidbey is a set of DataSource controls. The controls allow developers to bind data using a declarative syntax within an ASPX page. Let's take a look at a sample.
<asp:sqldatasource
id="SqlDataSource1"
runat="server"
selectcommand="select customerid, companyname from customers"
providername="System.Data.OleDb"
connectionstring="Provider=SQLOLEDB.1;Integrated Security=SSPI;
Persist Security Info=False;Initial Catalog=Northwind;
Data Source=localhost;Use Procedure for Prepare=1;
Auto Translate=True;Packet Size=4096;Workstation ID=SERVER1;
Use Encryption for Data=False;
Tag with column collation when possible=False">
</asp:sqldatasource>
The above control sets up a connection to a Sql Server database that other controls can now use to populate themselves. To setup a control to use the SqlDataSource control declared above you set the datasourceid of the control you would like to bind the data to.
<asp:dropdownlist
id="DropDownList1"
runat="server"
datavaluefield="customerid"
datasourceid="SqlDataSource1"
datatextfield="companyname"
autopostback="True">
</asp:dropdownlist>
When I frist saw some examples of the new data source controls I thought they seemed like a decent idea, however, the more I think about the implications of using the controls the more I'm beginning to think they're asking for trouble. Having the details of data connections interspersed with presentation code is simply not a good idea. I have a couple buddies who are just learning the .NET ropes and these types of features worry me.
On a day when so many are getting their first look at the future of Microsoft technologies, I am here at my office (take notice that my office is not at the PDC) working on some of the greatest technology that ever came out of Microsoft. That's right you guessed it I'm working with Site Server 3.0!
As I read all of Scott Hanselman's great little overviews of the keynote I sit here working with Site Server, and to make it even better our current instance of Site Server is running on NT4 and using a SQL 6.5 database. Now given the opportunity to see Longhorn, Avalon, Aero, Indigo, Whidbey, ASP.NET 2.0, and Yukon OR work with the wonderful platform that is Site Server I'm sure you would all pick the latter.
I sit here today at my desk, which again, is not at the PDC, to let you all know that although you think you are living the life with all the great stuff at the PDC, you in fact are not nearly as lucky as me. Long live Site Server!
A couple of days ago I came across Scoble's post over on LonghornBlogs.com entitled “How to Hate Microsoft.” When I saw the post I didn't really pay much attention to it. I gave it a quick skim but didn't actually read what Robert was saying. Today I found myself back at the post. Rather then ignoring it for a second time I decided to read what Mr. Scoble had to say.
Simply put, I love Microsoft. I've been developing with their technology for most of my professional career. I started working with VB and then moved to the wonderful world of the web when ASP rolled along. Using Microsoft technologies I've developed a lot of application for myself and clients. The one thing that I really liked early in my career was how fast I could get myself up to speed on the Microsoft platform. It always seemed like when I tried to do some of the same things on the Java platform it wasn't quite as easy.
As I've grown professionally the things I look for in a platform have shifted dramatically. Two years ago I was looking at what Java and J2EE provided developers and thinking that it might be time to leave the Microsoft side of the development world and turn to the dark side. The frustration of developing distributed applications on Microsoft technology had me on the verge of jumping ship. How much longer could I take DLL Hell?!?!
Then something happened. I attended a Microsoft event and heard about ASP+. It sounded promising, but I was skeptical. I had been bitten many times by Microsoft technology and wasn't sure what would become the .NET platform would be able to live up to the hype. I decided early on to adopt this .NET thing, so I got all the beta software I could and tried it out. I wrote several very simplistic applications in the beta 1 days and really liked what I was seeing. This was a cool platform!
Since that time I've embraced everything .NET and have never looked back. I still try and learn as much as I can about J2EE, Java, and all the other alternative technologies out there so that I can try and keep a open mind about the best platform choice for clients, but .NET isn't making that any easier.
So what does all this have to do with Scoble? What Scoble said in his post made me feel very confident in the decisions I made two years ago when I was thinking about jumping to the J2EE/Java world. As if all the talk about what's coming in .NET v2 wasn't enough! Scoble represents a significant change inside of Microsoft. They are opening up “their world” for all of us developers to see. They're giving us very early Longhorn bits, they're writing blogs about the internals of their operation systems, and platforms. They're embracing their developer community in a truly awesome way. I am more confident then ever that I made the right choice two years ago when I decided to stick with my Microsoft roots and embrace .NET. In the coming years I believe we will see a lot of truly amazing things come out of Microsoft. As a developer I'm extremely excited about all the killer functionality I'm going to be able to provide my clients. The future looks bright!
When an object is serialized using the XmlSerializer all properties are included in the serialization unless they are explicitly marked with the [XmlIgnore] attribute. When you serialize (of the ViewState nature) an object all the properties are included unless they are marked with the [NonSerialized] attribute. Currently in my entity framework all properties that should be persisted need to have a [Persist] attribute applied to them. As I was thinking tonight about this I realized that this is probably not the ideal design. 90% of the time all properties of an object will need to be persisted. A property that should NOT be persisted is the exception. So, rather then forcing users of my entity framework (yes, I know its just me) to apply the [Persist] attribute to every property, I'm thinking that I should create a [NonPersisted] attribute to mark only those properties that should not be persisted. Thoughts?
Option 1 - Mark all properties to be persisted with the [Persist] attribute.
public class Customer {
string _firstName;
string _lastName;
[Persist]
public string FirstName {
get { return _firstName; }
set { _firstName = value; }
}
[Persist]
public string LastName {
get { return _lastName; }
set { _lastName = value; }
}
public string FullName {
get { return _firstName + “ “ + _lastName; }
}
}
Option 2 - Mark only the properties that should NOT be persisted with the [NonPersisted] attribute
public class Customer {
string _firstName;
string _lastName;
public string FirstName {
get { return _firstName; }
set { _firstName = value; }
}
public string LastName {
get { return _lastName; }
set { _lastName = value; }
}
[NonPersisted]
public string FullName {
get { return _firstName + “ “ + _lastName; }
}
}
The last couple of nights I've been working on some updates to a site I developed 1.5 years ago. Each time I open up the solution and begin working on the updates I have this nagging temptation to re-write the core logic of the application. When I originally wrote the application I was just learning the .NET ropes and did a number of things that I don't particularly like.
I keep telling myself “The site works, leave it alone.” The tempations keep on coming. “Your only doing a couple minor updates, its not worth the effort.”
I've held off the temptations so far, but I'm getting weak....must....stay....strong. Must....not.....re-write!
A couple of months ago I came across TestDox (aka AgileDox).
TestDox creates simple documentation from the method names in JUnit test cases.
http://agiledox.sourceforge.net/
http://cgi.skizz.plus.com/blog/dev/archives/000113.html
This morning I had a little free time and thought it would be useful to have a version of TestDox for .NET. I opened up Google and was surprised to find that no one (as far as I could tell) has ported it yet. So I fired up VS.NET and coded it up. You can see what I ended up with at:
http://www.emxtechnologies.com/ntestdox
Almost all of the concepts were taken from AgileDox so if you don't like the way something is being done blame Chris Stevenson instead of me 
...just kidding Chris...well sort of. If you want to give it a try I would appreciate any feedback, suggestions, and critiques. As I said I just wrote it this morning so there hasn't really been much testing so don't say I didn't warn you!
TestDox was written by Chris Stevenson, of Thoughtworks so if you dig NTestDox you should really thank him since he did all the real “work”.
Today was the highly anticipated J2EE/Java vs. .NET debate within our technology department. To start the debate we defined a large enterprise scale application. We looked at the advantages and disadvantages of each platform and compared each against the following “criteria“:
- Scalability
- Performance
- Availability
- Globalization
- Security
- Integration with External Systems
- Business Workflow
I don't remember the exact breakdown of which platform took each criteria, but the majority of the wins that J2EE recieved was due to its maturity. Becuase it has been around longer then .NET there are many more options when you start looking at building a very large scale enterprise application.
During the debate it was clear that many of the Java folks felt .NET was an immature, unproven technology. Although I can't argue that .NET is as mature as J2EE, I certainly wouldn't say it's immature or unproven. I've seen case studies on a lot of very large companies developing some pretty serious systems with .NET. Do you think Microsoft would be building EVERYTHING (at least it seems) on something that was immature or unproven? I don't think so.
Some other areas where the Java folks felt they had an advantage was with the MVC frameworks available in Java (such as Struts), as well as with the number of vendors supporting Java (Sun, IBM, Oracle, BEA, etc.). The vendor support came into play when we started to consider options for application servers, intergration platforms, distributed transaction support, and etc.
Overall I'm pretty disappointed with the outcome of our debate. I really didn't do as good of a job as I I would have liked winning people over to .NET. I was out-numbered, but that's simply not an acceptable excuse.
What strong arguments would you have made for .NET? How would you have countered the “Java is more proven and mature” argument?
It's official! This Thursday will be the great Java vs. .NET debate at our technology department meeting. We've been planning on the debate for several weeks now and we're finally going to round up some of the Java guys who are off site to come back and duke it out. I'll obviously be arguing the .NET side, and obviously will dominate! ;-)
Java
- Cross platform - we all know this is only half true, and with Mono it's close to a non-issue (at least I'm hopeful)
- Maturity - I assume I'll have to concede this point to the Java guys. There are a lot more frameworks and etc. on the Java side. This is pretty evident if you look at the popular .NET frameworks, build tools, and unit testing tools - they all are ports of pretty established and mature java projects.
- Better IDE's - I haven't actually used any of the killer IDE's that I hear so many folks talk about but it certainly seems like products like IntelliJ provide a lot of killer features that we haven't yet seen with the .NET IDE's.
- Established Practices - Java has been around for a long time. Over the years many rules for Java development have been established among folks in the Java community. Things like don't use EJB's unless your forced into them, use MVC frameworks (struts) for UI development, and etc.
.NET
- ASP.NET - The power and flexibility offered by the the advanced features and functionality of ASP.NET is much better then anything on the Java side of the world. Just imagine the separation we're going to see in future versions!
- C# is a better Java - C# took many of the ideas and concepts of Java and made them better.
- More innovation - I'm sure I could get some heat on this argument but I firmly believe that their is more innovation going on within Microsoft then within many of the Java camps. .NET is a two year old platform and it has surpassed (or at least it will with v2.0) Java on many fronts. Imagine the separation we will see in the coming years!
- Language neutrality - The .NET Framework allows us to write our .NET applications in whatever language we choose. This allows folks to leverage the skills and expertise of their development staff and provides for greater choice when building applications.
- Web Services - I don't want to argue this point too much because I think the whole web services aspect of .NET is way over hyped. Many of the marketing materials available make it seem as if .NET == web services, clearly there is much much more to .NET then just web services. With that said the ease of creating web services on the .NET platform kicks the butt of the Java crowd.
- Performance - Yet another heated topic. Although I think you need to take any performance numbers with a grain of salt, every one I've seen (including ones by the java community) has shown .NET outperforming Java. Let's face it both platforms have areas where they will outperform the other, however, on a whole it seems that .NET wins more then it loses.
- Productivity - My belief is that the base class library, as well as the control libraries available within the .NET Framework allow developers to write applications faster and with fewer lines of code.
- The future of Microsoft is .NET - As many of you lucky folks will be able to attest to following the PDC, Microsoft is doing some really amazing things. Longhorn, Avalon, Indigo. Need I say more?
I'm sure I could go on but I don't want to give away ALL my material before the debate. What advantages and disadvantages am I missing? What do you believe is the better platform? Why? Come on folks give me some material!
One of the design decisions I made when I started working on my entity framework was in regards to how users of the framework would interact with entity objects. Rather then providing a manager object for working with the saving, deleting, and retrieval of objects from the data store I decided I wanted users of the framework to be able to work with the Entity objects directly. To quote Thomas Tomiczek of EntityBroker fame:
Having load, save, etc., methods on the objects is breaking a lot of patterns that are common. Stuff like responsibility is assigned wrongly etc. Using a manager - externally, not only internally - is an accepted pattern to handle this.
I definitely see Thomas' point. Tying the entity objects directly to manager classes, rather then having users interact with the manager classes may be giving the entity objects more responsibility then they should have. The real question for me is what's best for the developer? When you're working with business objects do you prefer to work with them directly:
Customer customer = new Customer();
customer.FirstName = “Steve”;
customer.LastName = “Eichert”;
customer.Address = “123 Maple Ave”;
// etc..
customer.Save();
OR, do you prefer to work with the entity objects through a manager class:
EntityManager manager = new EntityManager();
Customer customer = manager.Create(typeof(Customer)); // or maybe just: Customer customer = new Customer();
customer.FirstName = “Steve”;
customer.LastName = “Eichert”;
customer.Address = “123 Maple Ave”;
// etc..
manager.Commit(); // updated for Thomas
Now that you've decided which you prefer I'd love to hear why! Also if there are certain situations when you would choose one over the other please share them in the comments for this entry.
One of the design decisions I made when I started working on my entity framework was in regards to how users of the framework would interact with entity objects. Rather then providing a manager object for working with the saving, deleting, and retrieval of objects from the data store I decided I wanted users of the framework to be able to work with the Entity objects directly. To quote Thomas Tomiczek of EntityBroker fame:
Having load, save, etc., methods on the objects is breaking a lot of patterns that are common. Stuff like responsibility is assigned wrongly etc. Using a manager - externally, not only internally - is an accepted pattern to handle this.
I definitely see Thomas' point. Tying the entity objects directly to manager classes, rather then having users interact with the manager classes may be giving the entity objects more responsibility then they should have. The real question for me is what's best for the developer? When you're working with business objects do you prefer to work with them directly:
Customer customer = new Customer();
customer.FirstName = “Steve”;
customer.LastName = “Eichert”;
customer.Address = “123 Maple Ave”;
// etc..
customer.Save();
OR, do you prefer to work with the entity objects through a manager class:
EntityManager manager = new EntityManager();
Customer customer = manager.Create(typeof(Customer)); // or maybe just: Customer customer = new Customer();
customer.FirstName = “Steve”;
customer.LastName = “Eichert”;
customer.Address = “123 Maple Ave”;
// etc..
manager.Commit(); // updated for Thomas
Now that you've decided which you prefer I'd love to hear why! Also if there are certain situations when you would choose one over the other please share them in the comments for this entry.
In the comments for my recent post “More Fun With Attributes”, rbfigueira asked if I could provide the source for some of the custom attributes I had written. While I have thought about opening up the source for pieces of my entity framework, it isn't anywhere near ready. So with that in mind I thought the least I could do is dig up another example of using Attributes for validation of business objects.
Clemens Vasters of Newtelligence Ag put together a pretty nice example that is available at:
http://www.newtelligence.com/downloads/Events/Basta2001/ReflectionSample.zip
I wasn't able to find the original “article” that I read on the newtelligence site explaining the approach Clemens used in the above code, but you *might* be able to find a cached version of the page on google.
Robert Martin has an interesting post over on Artima about managing software projects like a business.
The bottom line for agile methods is that they provide the data that makes managing software projects possible. They allow a software project to be managed like a business.
One of the limitations of having read only properties is that you cannot use external objects to load up your classes with data retrieved from your data store. Since a read only field is by definition READ ONLY, a “loader” class cannot set the value of the property with a value from the data store. As an example lets take the following class.
public class Customer {
int _customerID;
string _name;
int _createdBy;
public int CustomerID {
get { return _customerID; }
set { _customerID = value; }
}
public string Name {
get { return _name; }
set { _name = value; }
}
public int CreatedBy