.Net Code Monkey RSS 2.0
 Saturday, April 05, 2008

Tonight, I stumbled upon, and then tested out, this useful article by the Wrox Team. It's all about printing WinForms in C#.

http://www.devarticles.com/c/a/C-Sharp/Printing-Using-C-sharp/

Hopefully you will find it as useful as I did. :-)

Friday, April 04, 2008 11:14:04 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
.Net | C#
 Thursday, April 03, 2008

It has been confirmed that the new Developer Lead will start working with us next month.  It should be interesting as neither myself or our other two application developers have met the applicant, so we are not sure what skill level he will have.

The other two developers have come up through the company and gained their skills along the way. Our senior developer (JA) came through the buying and merchandising department, starting with VBA in MS Excel, then VB6 and on to VB & C#.Net, while (PB) has come through from Logistics and I'm not sure his precise skill route, but he also codes in VB & C#.Net. Myself, I came into the company two years ago with basically only classic ASP and a whole lot of keeness to learn. I believe the other senior developer we had before he left also learned on the job too at another major uk clothing retailer, before joining NewLook.

As JA has so rightly pointed out, when the new guy turns up it will be good to see how our self taught standards and practices and skill levels stack up against a true professional from the industry. He has been programming in an OO approach for a fair few years and is very methodical and tends to follow some strict practices. For myself and PB it's only been a couple years that we have been programming in an OO approach. As a team, we have recently started to look into dependency injection and inversion of control, and JA is keen for our current project to utilise Spring.Net. We are hoping that the new chap can shed some light on if our intended development path is where the industry is going or if we are missing the point be a country mile.

Thursday, April 03, 2008 8:34:37 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
General

One of my on-going projects uses a light weight client to call a web service, which runs a fairly long running process, part of which will take at minimum five minutes. Testing has proved that the request to the webserver will cause a timeout. I belive the default is about 90 seconds. There are probably many ways to circumvent this problem, but the two that i am concidering are:

  • Increase the time out settings to cover the longest anticipated duration.
  • To implement fire and forget by the client, and let the webservice spawn an additional thread to carry out the long process, returning the request almost imeadiatley.

Increasing Timeout settings

Solution

From a little web reasearch it appears that there are three settings that may be able to assist me.

  • The timeout property on the webservice proxy
  • The http-runtime setting in App.Config of the calling assembly
  • The http-runtime setting in Web.Config of the webservice.

Pros

  • Allows trapping of exceptions during the process and passing them back to the client in the form of a SoapException.

Cons

  • Process time may vary over operational lifetime of project requiring changing of configuration files, and possibly recompliling everytime the threshold is exceeded.
  • If the request times out there is no way of knowing if the process is still running.

Fire and Forget

Solution

My second solution would be to use the BackgroundWorker to spawn a new thread in the code called the from the WebService's WebMethod.

Pros

  • Allows imediate return of the WebMethod request so very little risk of time out, and therefore virtually limit less total process time.
  • Because the client needs to request whether the process has finished any way, if an exception occurs this can be handled and the status relayed back to the client at the next request.

Cons

  • Requires state of progress or completion to be stored by webservice (in database, text file, or similar).
  • Requires the calling client to keep "asking" the webservice if the task has finished. This will involve more coding and the client having to "know" that it has to keep asking for the progress and or status of completion of the task.
  • Requires extra coding to provide client with information if an exception occurs during the process.

So which is the best method to choose? Well this is probably going to sound like a bit of a cop-out, but it really does depend upon the application and how it is to be used. Each solution has it merits and its drawbacks as you can see.

For the project that I am concerned with I will no doubt use the fire and forget solution so I am not limited to time outs, as one of the processes (Archiving) will gradually take longer and longer to complete over the working life of the application, and I do not wish to be having to change the timeout and recompile frequently. I am also concerned that the timeout required couls easily surpass acceptable limits.

So how would you choose to carry out this task? Do you have any other solutions? Can you see any more advanatages or disadvantages of using either of the two solutions presented? your thoughts are welcom as always.

To be continued...

Thursday, April 03, 2008 12:24:24 PM (GMT Standard Time, UTC+00:00)  #    Comments [1] -
.Net | C# | Long Running Processes | Web Services
 Tuesday, April 01, 2008

I'm sure most of us endeaver to keep the tightest scope possible for the members of classes we write. But I have a situation where I just can't seem to be able to keep the scope of members of my inherited class as tight as I would like.

What I am intending to create is a Job object that will inherit from a BaseJob object that will implement the IJob interface. While doing this I want to ensure the JobFactory member of the Job object is kept private and the Id member is public. Both of these members belong in the BaseJob object.

So I'll start with new assembly that will contain three interfaces; IJob, IIdentifyable and IJobFactory.

public interface IJob : IIdentifyable
{
    /// <summary>
    /// Gets or sets a reference to the factory that created the IJob object.
    /// </summary>
    IJobFactory JobFactory { get; set; }
}
/// <summary>
/// Represents the signature for an object that is identifyable
/// </summary> public interface IIdentifyable { /// <summary> /// Gets or sets a reference to the identity of the IJob object. /// </summary> int Id { get; set; } }

/// <summary>
/// Represents the signature required for a job factory.
/// </summary>
public interface IJobFactory
 {
     /// <summary>
     /// Creates an object that implements the IJob interface.
     /// </summary>
     /// <returns>Returns an object that implements the IJob interface</returns>
     IJob Create();

     /// <summary>
     /// Saves the current job
     /// </summary>
     void Save(IJob job);
 }

IJob has a member which will be used to hold a reference to an object (that implements the IJobFactory inteface) that created it. It will also have a Id member implemented through the IIdentifyable interface. IJobFactory has a method for returning a newly created object that implements the IJob interface and a method to save an object that implements the IJob interface. Both interfaces must be public as they need to be seen from outside the assembly. As far as I am aware you canot declare the scope of the methods in an interface so each will be of the same scope as the interface.

I now need to another new assembly which will contain a base class (BaseJob) for my Job object to inherit from. I create a reference to the interfaces assembly, and allow the BaseJob class will implement the IJob interface from it.

/// <summary>
/// The base class that all Job objects should inherit from.
/// </summary>
public abstract class BaseJob : IJob
{
    private int _id;
    private IJobFactory _jobFactory;

    #region IIdentifyable Members

    /// <summary>
    /// Represents the identity of an Job
    /// </summary>
    public int Id
    {
        get { return _id ; }
        set { _id = value; }
    }

    #endregion

    #region IJob Members

    /// <summary>
    /// Gets or sets a reference to the factory that created the IJob object.
    /// </summary>
    public IJobFactory JobFactory
    {
        get { return _jobFactory; }
        set { _jobFactory = value; }
    }

    #endregion

}

Now, I would like to set the scope of the BaseJob's Id and Jobfactory members as protected, do they can only be seen by objects that inherit from the BaseJob object. However if I try and make the scope any tighter then VS advises me of an error when I try to build.

Error 1 'BaseJob' does not implement interface member 'IJob.JobFactory'. 'BaseJob.JobFactory' is either static, not public, or has the wrong return type.

So as far as I can see it has to stay public. Any way on to my Job object now. In a third assembly, which has a reference to both the base class assembly and the interfaces assembly,  I create the Job class.

public class Job : BaseJob
{
    public Job(int id, IJobFactory jobFactory) : base()
    {
        base.Id = id;
        base.JobFactory = jobFactory;
    }
}

The Job class has a contructor which allows me to pass in the identity and the JobFactory which is used to create it ( I hope to write an post / question on dependency injection next!). My problem is I don't intend the JobFactory property of the Job object to be visiable outside the class code, so ideally I would like to scope it as private. However it is an inherited member that already has a scope of public. I can quite clearly see the member like so...

class TestClass
{
    Job _job;

    public TestClass()
    {
        _job = new Job();
        _job.JobFactory = ...;
    }
}

The only way I can see to hide the member is by overriding the JobFactory member to the Job object with the new modifier like so.

private new IJobFactory JobFactory
{
    get { return base.JobFactory; }
}

Is this really the best way to go about this, or am I doing something fundementally wrong? Your comments appreciated!

 

Tuesday, April 01, 2008 8:35:00 PM (GMT Standard Time, UTC+00:00)  #    Comments [0] -
.Net | C# | Inheritance | Interfaces | Scope
Archive
<April 2008>
SunMonTueWedThuFriSat
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910
Blogroll
 Clemens Vasters
 Harry Pierson
Passion * Technology * Ruthless Competence
 Joshua Flanagan
A .NET Software Developer
 Michael Schwarz's Blog
Developing applications on the Microsoft platform since Windows 3.1!
 Omar Shahine
Yet another Microsoft blogger
 Scot GU
Scott Guthrie lives in Seattle and builds a few products for Microsoft
 Scott Hanselman
Programming Life and the Zen of Computers
 Tom Mertens
Tom's corner
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2014
Duane Wingett
Sign In
Statistics
Total Posts: 49
This Year: 6
This Month: 1
This Week: 0
Comments: 43
Themes
Pick a theme:
All Content © 2014, Duane Wingett
DasBlog theme 'Business' created by Christoph De Baene (delarou)