Sunday, November 28, 2004

Partial Classes in C#

With C# 2.0 it is possible to split definition of classes, interfaces and structures over more than one files.
This feature allows you to do a couple of fancy things like:

1- More than one developer can simultaneously write the code for the class.

2- You can easily write your code (for extended functionality) for a VS.NET generated class. This will allow you to write the code of your own need without messing with the system generated code.

There are a few things that you should be careful about when writing code for partial classes:

1- All the partial definitions must preceede with the key word "Partial".
2- All the partial types meant to be the part of same type must be defined within a same assembly and module.
3- Method signatures (retrn type, name of the method, and parameters) must be unique for the agregated typed (which was defined partially). i.e. you can write default constructor in two separate definitions for a particular partial classe.

Now here is the code:
File 1:

public partial class myPartialClass
{
/*
///
///
///

public myPartialClass()
{
Console.WriteLine(" I am in partial class in other Partial.cs");
}*/

public myPartialClass(string pString)
{
Console.WriteLine("I am in a partial class in Partial.cs. The parmeter passed is: " + pString);
}

public void doSomethingElse()
{
Console.WriteLine(" I am in Partial.cs ");
}
}


File 2:

public partial class myPartialClass
{
public myPartialClass()
{
Console.WriteLine(" I am in a partial class in Program.cs");t
}

public void doSomething()
{
Console.WriteLine(" I am in Progam.cs ");
}
}

class TestProgram
{
static void Main(string[] args)
{
/// see the classe are partial but the object is complete.
myPartialClass myCompleteObject = new myPartialClass();
myCompleteObject.doSomething();
myCompleteObject.doSomethingElse();
Console.ReadLine();
}
}



Friday, November 19, 2004

SOA is some thing beyond ORM

I am following this thread at TheServerSide.NET

I replied on the SOA vs ORM aspet as follows:

Once you recieve message only then you are in side your domain and can work with whatever methodology you are using. And in case you are using Object Orientation and ORM then, as you said, you may use these messages for initiating, terminating, etc your business objects.

So, I believe ORM and SOA can not fit in the scene together i.e. if you are talking about SOA then you are beyond ORM and if you are talking about ORM then you are underneath SOA.

Thursday, November 18, 2004

.NET Transactions in Multi Tier ?

I want to discuss some more helpful issues related to NTier .NET Application Development. The latest one is..

Which is the best and prefered place to initiate the Transaction in .NET Multi Tier Application.

1. It should be handled in Database Layer with ADO.NET built in transaction management.
2. It should be start from the business layer as most of the times transacion process is some sort of business procss rather than database process.

3. If we start transation from the business layer then what is the best approach.

Hope most of them will come with some good arguments about this important issue of Multi Tier Applications.

Regards
Waqas
Moderator (pakistan_dotnet)


My response:

1. Database Layer:
I will say a big no for this. Because not only these transactions are business processes, usually, but also at times they may span more than one database. So to say, if your transactions span multiple databases and/or are long running processes then database layer level transaction handling is almost out of the question. However for small apps and simple transactions ADO.NET transactions can be the best and most efficient way of implementing transactions. By the way unless and until I am using COM+, all the transactions drill down to this layer for execution eventually!

2. Business Layer:
I usually implement Transactions in applications Business Layer. I do it because, I believe, this is the logical place where I should be implementing my business processes.

3. Business Layer Transactions: Best Approach:
If I am using some application framework then I will make sure that my framework provides me the support of encapsulating transactions in Business Layer(similar is the case with DAL). We usually have a Manager (for CRUD and other related functionality) class for each domain entity and then based on requirements we also have enterprise managers for some of our entities, these enterprise managers inherit from some base class in our application framework which in turn implements IServicedComponent of System.EnterpriseServices. In this way COM+ support trickles down to our Business Logic Layer.
Even if you don't have such application framework then you can do the transactions your own way in BLL.

Saturday, November 06, 2004

Google Page Index .. going

Wow Cool, my page rank is 4/10 .. :)