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 {
get { return _createdBy; }
}
}
Now assume that your data store has a record with the following data:
Customer ID Name Created By
12 Joe Smith 1
Unless you load your Customer object within either a method of the customer class or an inner class you will not be able to set the _createdBy field to the value in the data store. Although you will incur a small performance hit, you can use Reflection to accomplish the task as shown below:
FieldInfo field = c.GetType().GetField("_createdBy", BindingFlags.Instance | BindingFlags.NonPublic);
field.SetValue(c, dataStore[“CreatedBy“]);
In years gone by I always had my classes load themselves with the data from the data store, however, in an attempt to follow the Single Responsibility Principle I've changed my ways. Using the method described above is one way to slip around the limitations that you may run into while trying to follow the SRP
One of the features I've been wanting to add to my entity framework is the ability to have configurable entity manager classes. Let me give a brief background to explain what the architecture of the entity framework is so that you can see what I've been wanting to do.
At the center of my entity framework is the EntityObject class. All my custom entity objects derive from EntityObject. The EntityObject class uses an EntityManager class to manage the persistence of objects to a given data store. As of right now I only have a Sql Server entity manager class (SqlEntityManager), and a mock entity manager class for use in unit testing, however, in the future I hope to add additional entity manager classes for persisting my entity objects to Xml, Oracle, and Access.
Now back to what I've been wanting to add. Up until today my EntityManagerFactory class always returned a SqlEntityManager class. Since I'm beginning a couple of new projects and using TDD I needed to be able to set my classes to use the MockEntityManager class. To accomplish this I needed to alter the EntityManagerFactory class to use the config file to determine the type of EntityManager class to create. I also wanted the ability to configure each type of EntityObject to be able to use different EntityManager classes, since I may want some classes to use the SqlEntityManager classes, and others to use the MockEntityManager class. To accomplish this I implemented the following code in the EntityManagerFactory class:
internal IEntityManager GetEntityManager(EntityObject entity) {
IEntityManager entityManager;
string entityTypeName = entity.GetType().Name;
// check to see if we already have a mapping for this type of entity object
if(_lookups[entityTypeName] == null) {
// read in the entity manager to use for the given entity object type
XmlElement element = (XmlElement) ConfigurationSettings.GetConfig("entityFramework");
XmlNode node = element.SelectSingleNode("entityManager/class[@name='" + entityTypeName + "']/..");
// if a IEntityManager mapping isn't found for the class use the default
if(node == null)
node = element.SelectSingleNode("entityManager[@default='true']");
if(node != null) { // create the IEntityManager class
string className = node.Attributes["type"].Value;
entityManager = (IEntityManager)Type.GetType(className, true).GetConstructor(Type.EmptyTypes).Invoke(null);
_lookups[entityTypeName] = entityManager;
} else {
// default to SqlEntityManager
entityManager = new SqlEntityManager();
_lookups[entityTypeName] = entityManager;
}
} else { // we already have a mapping so read it...
entityManager = (IEntityManager) _lookups[entityTypeName];
}
return entityManager;
}
As you can see from the code above I keep a mapping of IEntityManager classes for each type of EntityObject. If the _lookups hashtable (used to hold the mappings) doesn't yet contain an entry the class I read the value from the configuration file. If the config file doesn't contain a mapping for the individual type of class then the default IEntityManager is mapped to the EntityObject. I still need to add some logic for invalidating mappings when the config file is updated as well as add a couple of other configuration settings but I'm getting close to having the configurability of the system to where I want it.
<?
xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="entityFramework" type="emxTechnologies.Core.Configuration.EntityFrameworkConfigurationSectionHandler,emxTechnologies.Core" />
</configSections>
<entityFramework>
<entityManager default="true" type="emxTechnologies.Cms.Tests.MockEntityManager,emxTechnologies.MyProject.Tests">
<class name="Customer"/>
<class name="Employee"/>
</entityManager>
<entityManager type="emxTechnologies.Core.EntityObjects.SqlEntityManager,emxTechnologies.Core">
<class name="Order"/>
<class name="OrderDetail"/>
</entityManager>
</entityFramework>
</configuration>
Over the last two years I've written a pretty decent amount of code in C#. Some of the code has been in code behind pages but the majority has been in class libraries. When I first started writing some of my class libraries I organized my classes into namespaces by the type of class. So as an example I had an “Attributes“ folder for all my custom attributes, an “Exceptions” folder for all my exceptions, and so on. At the time it seemed to make sense. Each type of class was stored away in its very own folder so that it would be easy to find when necessary. What I didn't think about was the usability of the API's. Many of my business objects required the custom attributes, as well as custom exceptions. In order to use these I either needed to fully qualify the classes or I needed to add a using statement for each namespace. While this isn't a huge deal it isn't as usable as it should be. If the attributes and exceptions were created solely for use with my business objects then the attribute and exception classes should be in the same namespace as the business objects. Users of my API's should not have to go searching for the namespace of a custom attribute or custom exception. In summary, let me just simply say...think about the usability of your API's!
Attribute based programming is one of my favorites aspects of working with .NET. The ability to attach meta data to classes, properties, methods, and etc allows me to create some really fun pieces of functionality. I'm using attributes to supply my entity framework with all sorts of information about the properties of my classes. Using attributes I can tell the framework that the property should be persisted, that it should NOT be auto-loaded, that it is required, that it must have a value that is less then, greater then, or equal to a certain value, or that the property must have a certain length (either min or max). I can then use all this meta data to generate dynamic assemblies on the fly. This provides for a very lightweight class with lots of functionality.
public class Customer : EntityObject {
string _firstName = String.Empty;
string _lastName = String.Empty;
string _company = String.Empty;
[Persist, Required, MaxLength(100)]
public string FirstName {
get { return _firstName; }
set { _firstName = value; }
}
[Persist, Required, MaxLength(100)]
public string LastName {
get { return _lastName; }
set { _lastName = value; }
}
[Persist]
public string Company {
get { return _company; }
set { _company = value; }
}
public Customer(int customerId) : base(customerId) {
}
}
The sample class above is extremely lightweight but with the power of attribute based programming the class is also extremely functional. This class can be saved to the data store, deleted from the data store, retrieved from the datastore and validated (using required, MinLength, MaxLength, etc) without the need to write any code besides what is seen above. You gotta love the power and flexibility that the .NET Framework provides!
Over the course of the last four years I've written a lot of web based applications for clients. The applications started pretty simplistic and over the years have gotten more and more complex. The one thing that has stayed the same over the years is the fact that the applications have been browser based. This past week one of my colleagues posed a question that made me think about how much longer this will be the case. The question he asked was something like this....
“If you had the option of choosing to create either a web (browser) based application or a smart WinForms client for a custom Intranet application which would you choose?”
The first thought I had was to choose web based, but after another split second of thought I changed my mind. Many of the reasons for sticking with web based applications have been nullified by the web deployment features available in .NET. Although I haven't begun trying to sell clients on smart client applications I think it might be time to start. Smart clients can provide users with a richer user interface while still providing many of the benefits of a web based application. Future versions of the .NET Framework will surely make this even more true. Is it time to move to smart clients? I think so!
How do you organize your classes. The typical layout for my classes goes something like this....
public class MyClass {
#region Private Variables
string _myString;
int _myInt;
bool _myBoolean;
#endregion
#region Public Properties
public string MyString {
get { return _myString;}
set { _myString = value;}
}
// other properties
#endregion
#region Constructors
public MyClass() {
}
#endregion
#region Public Methods
public string MySpecialMethod(int value) {
// blah...
}
#endregion
#region Private Methods
#endregion
}
The one thing which I've been switching up lately is where I place my private variables and public properties. I've always placed them at the top of my classes but have recently started placing them at the bottom since they seem to be “less important” then my constructors, and public methods. So....how do you organize your classes?
I’ve recently come across a couple articles and postings regarding unit testing, and more specifically whether or not to include the database in the unit tests.
Including the database in the unit testing does require more work but I see some benefits:
- Validate the stored procedures function as expected.
- Provides an overall integration test for the application and database.
- Forces you to think about deployment, integration, and setup of the database from the start.
- Forces you into a one click build, from scratch, including the database.
There are disadvantages as well:
- Have to spend more time thinking about how to fit the database in with the unit tests.
- Need to write scripts OR DTS packages to setup the database in a clean state.
- Need to worry about cleanup of any data inserted during the running of the unit tests.
- The tests will take longer to run when its running against the real database rather then just a Mock object.
Overall I like a happy balance between the two alternatives. I think including the database in unit tests can help the overall validity of the entire application. With that said I think there are definitely times when NOT including the database is the way to go. Perhaps as I get more comfortable with using Mock objects in place of the database my opinion will change….
I’ve recently come across a couple articles and postings regarding unit testing, and more specifically whether or not to include the database in the unit tests.
Including the database in the unit testing does require more work but I see some benefits:
- Validate the stored procedures function as expected.
- Provides an overall integration test for the application and database.
- Forces you to think about deployment, integration, and setup of the database from the start.
- Forces you into a one click build, from scratch, including the database.
There are disadvantages as well:
- Have to spend more time thinking about how to fit the database in with the unit tests.
- Need to write scripts OR DTS packages to setup the database in a clean state.
- Need to worry about cleanup of any data inserted during the running of the unit tests.
- The tests will take longer to run when its running against the real database rather then just a Mock object.
Overall I like a happy balance between the two alternatives. I think including the database in unit tests can help the overall validity of the entire application. With that said I think there are definitely times when NOT including the database is the way to go. Perhaps as I get more comfortable with using Mock objects in place of the database my opinion will change….
Are C# Xml comments as good as they seem? When I first heard about the Xml commenting available within C# I thought it was a great addition to the language. My first couple of projects I tried to remind myself to enter thorough Xml comments for my classes, and methods. After a while I had myself pretty well trained. Each method written got a nice block of Xml comments describing the function.
The more projects I work on the more I'm beginning to think Xml comments aren't all they're cracked up to be. They are a serious violation of the Don't Repeat Yourself (DRY) principle, and they've got me thinking about alternatives. Does it really make sense to have a big old comment block at the top of every method? Shouldn't well written code be self documenting?
I received some pretty good feedback on my C# Curly Braces Style post so I thought I'd list a couple other stylistic items to see if anyone has any strong feelings for or against the options presented...
- How do you name class level variables? I usually use a _ but am somewhat inconsistent when I'm doing ASP.NET work because of the way I name my web controls.
string _myString;
vs.
string myString
- How do you initialize class level variables? When they are declared or in the class's constructor? Why?
string _myString = String.Empty;
vs.
string _myString;
public MyClass() { _myString = String.Empty; }
I'm sure there are a lot of other items that could be brought up as well but most of them are covered by:
I'm currently evaluating commercial shopping cart products written in .NET. One of my clients is looking to build an e-commerce site and they don't have the budget to write it from scratch to meet their specific need. In an attempt to still win some business from them I'm looking to propose a off the shelf shopping cart / e-commerce product that can be customized and enhanced with any additional features they require. Any suggestions? Anyone used DotNetCart?
I've always been an “open curly brace on a new line” kind of guy.
public void MyMethod()
{
DoWork();
}
Just recently I've been finding myself pulled to the dark side, better known as:
public void MyMethod() {
DoWork();
}
What do you prefer and why? If you were putting together some style guidelines what would you use?
Yesterday I was adding some paging to a datagrid listing that was getting out of control. Since the number of records was pretty significant using the DataGrid's built in paging wasn't an option. While I was working on the paging I decided to take a peak at the queries being used to bring back the results. I didn't write them so I wanted to get a feel for “the look“ of the data being returned. I opened up query analyzer and ran the query. Then I waited....and waited....and waited. As I sat there waiting for the query to return I thought to myself, “man there must be a frigging bazillion records here”. Then the results popped up with a whopping 8 rows of data. I sat there asking Query Analyzer “Are you telling my I just waited 50 seconds for 8 records!?!”, no answer. It was clear Query Analyzer was too embarrased to even try and give an explanation.
After a little investigation a colleage and I found that the problem was due to some missing indexes on the tables being queried. After adding the indexes the query brought back the 8 records almost immediately. The moral of the story...make sure you have your indexes right!