Rants Tagged with “.NET”
via The Serverside .NET!
Enjoy
I've spent the last few days extending Reporting Services for a client. I am very impressed by their open model, I just wish that there was more 3rd Party support for designers. The
Visual Studio .NET designer is just ok, not great. And a conversion from Crystal to RDL would really rock.
Richard Blewett (of DevelopMentor fame) has a great piece on the insidious nature of this combo. Take a look, its worth it to understand what's going on.
I have finally gotten sick of GotDotNet's flakyness and moved the source and installer to my website. I am looking for a new home and may end up at SourceForge. If you have had any problems with the installer or finding the source, please visit
http://wildermuth.com/powertoys.
Recently I was talking with Rocky Lhotka and he said something interesting:
“Just when we got good at Client-Server, they switched things and had us doing n-Tier applications. Just when we got good at n-Tier development, internet applications took off.”
In my opinion he is right. It is interesting because client-server and n-Tier applications still exist, especially in enterprise development. I think we're good at client-server and n-Tier. The problem is that I think that much of browser based development attempts to apply n-Tier development.
What do I mean? In simple words, the web server is the middle tier. The browser is the client tier.
The idea behind n-Tier development is being able to separate the data work into a tier that can be scaled out. Luckily we know how to scale out webservers (into farms). Since we are securing webservers, we can isolate security issues from the client...just like we've done in n-Tier development.
I've had time lately to think about the nature of data in development lately. I've been talking with Rocky Lhotka and Michael Earls about it (as well as number of others) about the issues with dealing with data in applications.
The first camp is all about writing Business Objects. In this camp, you write classes that encapsulate the data, the data access and business rules about that data. This camp was the way to do it for years now. It proliferated in the Client-Server and n-Tier architecture camps.
Rocky Lhotka espouses his excellent CSLA.NET framework. If you are going the business object road, I wholeheartedly recommend it. It is designed around allowing object to exist locally or on separate servers through remoting.
The second camp is that data is all about data, so data is just a message to some system. With the excitement around Service Oriented Architectures (SOA), this view is starting to prevail.
Somewhere in the middle is where I sit. I think that data and business rules belong together, but the data access can be disconnected from it. So this is the interesting fact in my opinion...there are reasons to have the data access separated from the end users' machines (so perhaps remote data access), but once in the client, you want to have the business logic (and schema) as close to the client as possible. The closer it is to the client, the better it should scale. I don't like to see finely grained data access happening. Even in client-server apps, the more coarsely grained the data access, the better it should scale IMHO.
There is more I want to say on this, so stay tuned. I will be posting every day about this.
Tomorrow: “n-Tier, gone tomorrow”
I was taking a refresher MCSD test today to get ready to take one of the tests and came upon a question that is wrong. But it does infer that there is some confusion about how transactions are propogated to commands...or may be evidence that it is a bug. For example:
SqlConnection conn = null;
SqlTransaction tx = null;
try
{
// Create a new Connection
conn = new SqlConnection("Server=.;Database=Northwind;Integrated Security=true;");
// Open the Connection
conn.Open();
// Start a Transaction and create a new Command
tx = conn.BeginTransaction();
using (SqlCommand cmd = new SqlCommand())
{
// Set the Connection to the command
cmd.Connection = conn;
// NOTE: I do not explicitly set the TX to the Command
//cmd.Transaction = tx;
// Insert new values and execute it
// (within the transaction)
cmd.CommandText = @"INSERT INTO Customers (CustomerID, CompanyName)
VALUES ('ZZZZY', 'My New Company');";
cmd.ExecuteNonQuery();
// Insert new values, but the table name is wrong
cmd.CommandText = @"INSERT INTO Companies (CompanyID) VALUES('ANother Company')";
cmd.ExecuteNonQuery();
// We should never get here since the query is wrong
tx.Commit();
}
}
catch (Exception ex)
{
// Rollback the tx if error'd
if (tx != null) tx.Rollback();
}
finally
{
tx.Dispose();
// Close the connection just in case
if (conn != null)
{
conn.Close();
conn.Dispose();
}
}
This code fails because I do not explicitly set the transaction to the command. Unfortuately, you must set the connection and the transaction. This seems like a bug because you cannot execute a command on the connection (that has an pending transaction) without throwing an error.
The practice test asked me to specify a single missing line of code, so I could either set the command's connection property or it's transaction property, but not both. I suspect that there is confusion inside of MS about what is the expected behavior. But for now, I will just continue to set both and know that the test is wrong....
Part 1: Coupling Objects
I have been having a conversation about coupling of objects at the interface level. While I am not a fan of coupling objects together, I would like to be able to shortcut some factory code to make the interface be more intuitive. For example, here is code that decouples the interface:
class Foo
{
// ...
Guid _barID;
public Guid BarID
{
get { return _barID; }
}
}
Foo foo = new Foo();
Bar bar = Bar.GetBar(foo.BarID);
Whereas I don't want to tie the objects together, but simply call the factory (the GetBar method) within the Foo class to make getting objects easier and more intuitive. For example:
class Foo
{
// ...
Guid _barID;
public Guid BarID
{
get { return _barID; }
}
public Bar GetBar()
{
return Bar.GetBar(_barID);
}
}
Foo foo = new Foo();
Bar bar = foo.GetBar();
Not much different, but it makes the interface a bit clearer about how to get a Bar from Foo. This assumes some information about how assemblies are built. This does not work well if you have circular references in different assemblies. But in most of the project I have worked on, we use larger assemblies so this happens much more infrequently.
Part 2: Assembly Loading
As I was discussing it, the topic came up of which is better, more small assemblies, or fewer large assemblies. The argument comes down to this:
More small assemblies: Loading less code into memory at a time
Fewer large assemblies: Fewer Assemblies means a better working set.
It is my memory (though possibly flawed) that larger assembies really don't worry about loading lots of code because the real code loaded in the JIT'd code. JIT'd code is certainly created as necessary on a method by method basis. The part my memory is more unsure about is whether all the IL or just the Metadata is read into memory. If all the IL is read in, then the smaller assemblies position has a point.
Any feedback (whether as comments or e-mailed to me directly) is welcomed.
I can't decide if this is good or bad. I like the idea of developing against different OS's, but I expect that since Mono is a subset of the .NET Framework, it will not be as straightforward as they intend it to be.
I just wanted to give a shout out to Andy Smith of MetaBuilders ASP.NET controls. I regularly use his DialogWindow and FirstFocus controls. He has a number of controls on his site that are just great, but I can only speak for those two. My $0.02 review of them are:
- DialogWindow: This control is great in allowing a window to be opened and mimic a dialog window. Until the pop-up window is closed, the user can't play around with the main window. Setting these up is very trivial.
- FirstFocus: This control allows you to specify a control that will get focus when a user opens a form. This gets around my pet peeve around authors of websites that have forms forgetting to set the focus to the first control on a form. With this control, you drop it on a form and just specify the name of the control and it just happens.
Great work Andy!
