Let me explain why the deliberations on the DAL are taking me some time to get through. This is what keeps going around in my head when I think about the structure of the DAL.
If I build the DAL as a web service, it will be globally accessible in a (programming) language neutral way and will support re-use and loose coupling. Great. However, it could end up being too complicated and slow and in addition multiple BL services would then depend on ONE service which sort of defeats the object of SOA (in a pure SOA architecture the services are independent).
So, should I pursue a pure SOA architecture and split the database into several (smaller) databases, one for each BL service and then have each BL service have its own Data Access logic? Surely this will lead to code duplication?
So then I head this way:
I should forego the pure SOA architecture and create a single data access DLL (the DAL) that would be referenced by each BL service. That way I would not have any duplication of Data Access code and given that there is a single database then any change in the database or DAL would result in a change to just the DAL (and maybe a BL service that required it). My BL would be decoupled from the database.
However, the same arguments could be said for making the DAL a service and not a DLL – each BL service would reference the DAL service (instead of a DLL). Equally, a single DAL DLL could end up being too complicated and slow.
And so round and around I go. I’m not normally this indecisive …
Tuesday, 30 April 2013
Architecture Diagram
I'm still pondering the architecture for Project Sputnik, but I am am settled on a (fairly classic) four-layer/tier solution (diagram below).
Still not decided on how the DAL will be structured though. I may draw up the different structures that I am considering and then share them all before I finally settle on one and move on.
Still not decided on how the DAL will be structured though. I may draw up the different structures that I am considering and then share them all before I finally settle on one and move on.
Saturday, 27 April 2013
Development Environment
So this afternoon I've put together the Dev Env for Project Sputnik. I have built a Virtual PC comprising Windows Server 2008, SQL Server 2008, IIS7 and Visual Studio Pro from my MSDN subscription, plus some of the usual extras that you need.
I think I'm ready to go...
I think I'm ready to go...
Architecture
For the last couple of days I have been thinking about the architecture for Project Sputnik. It is important that I get it right so that it doesn't bind the development to a particular path or style but rather lends itself to casual stop-start, flexible development whilst providing a solid, scalable, adaptable structure to build upon.
That may seem like a lot of buzzwords thrown randomly about to make it sound like I know what I'm talking about, but that isn't the case. My time is precious & I will be developing this in my free time so rather than waste time developing, ripping up & restarting then re-developing, I want to do it only once.
I am particularly focussing on the data-access aspect of the architecture right now. I would like to get a single point of access if possible, even if the DAL comprises multiple classes, but a single place to work on/tweak/adapt for differing data providers would be ideal. My concerns about this concept though are around performance, particularly in a many user scenario.
I will continue my deliberations and research for now.
Wednesday, 24 April 2013
Step 2
In keeping with my previous post about attempting the work and then blogging about it afterwards, this post details what happened when I tried to point the existing app to the new installation of SQL Express...
In the VB6 world, my app had a single class that handled data access. A true single point of contact for the database. Everything was contained in it and to move to SQL would have been simple: Change the one class to communicate with SQL and off you go.
When I started the .NET port I tried to continue in the same way but quickly realised that it just didn’t work that way anymore. I didn’t understand the subtleties of .NET and so ended up using DataSets and TableAdapters in the form designer for each form that needed it. The project had a DataSet designer that graphically defined the links between the tables and so on.
Moving away from the Access database to SQL Server was therefore going to be tedious as there were numerous places that would need to be changed and then checked. But not to be put off I gave it a go!
First off, my Development Environment is contained in a Windows 7 Virtual PC, whereas I installed SQL Express on the main OS so I can use it for both Development and Production. So, fire up the VPC, load up Visual Studio 2010 and open the current project.
To ensure that I knew that during debugging there could be no way that data was being read from Access I renamed the Access database so that all data had to come from somewhere else (SQL hopefully).
Debugging the app threw an expected error “Could not find file 'C:\Users\All Users\KCN\Office Manager\OfficeManager.accdb'.” Sweet.
Next, the connection string that was held in the settings file was changed from “Provider=Microsoft.ACE.OLEDB.12.0;Data Source="C:\Users\All Users\KCN\Office Manager\OfficeManager.accdb"” to “Provider=SQLOLEDB;Data Source=MainPC\SQLExpress;Initial Catalog=OfficeManager;User ID=sa;Password=<hidden>;”
Debugging the app showed it didn’t work though! As the development environment was on a Virtual PC it was unable to connect to SQL Express on the host. Using this page I had to enable remote connections to SQL Express, enable TCP/IP, set the port to 1433 and then play with Windows Firewall to open ports 1433 and 1434 in both TCP/IP and UDP.
Finally a connection!
Opening the app and reading data worked fine, although the performance was PAINFULLY slow.
Testing a data write threw an immediate error of "Incorrect syntax near '`'." Hmmm. It quickly became obvious that it was never going to work as the SQL commands embedded in the DataSetDesigner were for Access and not SQL so things like "INSERT INTO `AssetTypes` (`AssetType`) VALUES (?)" are obviously going to fail.
I can see that there is no easy way to move the current app to SQL. I’m going to have to re-create the data schema in the application from scratch and then check every point of data access.
The question is this; is it worth all the additional effort?
Probably not. I think we'll chalk this one up as a failure and move on. I'll leave the current app as it is ...
In the VB6 world, my app had a single class that handled data access. A true single point of contact for the database. Everything was contained in it and to move to SQL would have been simple: Change the one class to communicate with SQL and off you go.
When I started the .NET port I tried to continue in the same way but quickly realised that it just didn’t work that way anymore. I didn’t understand the subtleties of .NET and so ended up using DataSets and TableAdapters in the form designer for each form that needed it. The project had a DataSet designer that graphically defined the links between the tables and so on.
Moving away from the Access database to SQL Server was therefore going to be tedious as there were numerous places that would need to be changed and then checked. But not to be put off I gave it a go!
First off, my Development Environment is contained in a Windows 7 Virtual PC, whereas I installed SQL Express on the main OS so I can use it for both Development and Production. So, fire up the VPC, load up Visual Studio 2010 and open the current project.
To ensure that I knew that during debugging there could be no way that data was being read from Access I renamed the Access database so that all data had to come from somewhere else (SQL hopefully).
Debugging the app threw an expected error “Could not find file 'C:\Users\All Users\KCN\Office Manager\OfficeManager.accdb'.” Sweet.
Next, the connection string that was held in the settings file was changed from “Provider=Microsoft.ACE.OLEDB.12.0;Data Source="C:\Users\All Users\KCN\Office Manager\OfficeManager.accdb"” to “Provider=SQLOLEDB;Data Source=MainPC\SQLExpress;Initial Catalog=OfficeManager;User ID=sa;Password=<hidden>;”
Debugging the app showed it didn’t work though! As the development environment was on a Virtual PC it was unable to connect to SQL Express on the host. Using this page I had to enable remote connections to SQL Express, enable TCP/IP, set the port to 1433 and then play with Windows Firewall to open ports 1433 and 1434 in both TCP/IP and UDP.
Finally a connection!
Opening the app and reading data worked fine, although the performance was PAINFULLY slow.
Testing a data write threw an immediate error of "Incorrect syntax near '`'." Hmmm. It quickly became obvious that it was never going to work as the SQL commands embedded in the DataSetDesigner were for Access and not SQL so things like "INSERT INTO `AssetTypes` (`AssetType`) VALUES (?)" are obviously going to fail.
I can see that there is no easy way to move the current app to SQL. I’m going to have to re-create the data schema in the application from scratch and then check every point of data access.
The question is this; is it worth all the additional effort?
Probably not. I think we'll chalk this one up as a failure and move on. I'll leave the current app as it is ...
Mike's Knowledgebase
I found this post REALLY helpful and worth a couple of hours working through the tutorials. It takes you through the process of setting up a WCF web service with a JSON payload to perform CRUD operations against SQL Server, and ultimately consume the service(s) in iOS.
http://mikesknowledgebase.com/pages/Services/WebServices.htm
http://mikesknowledgebase.com/pages/Services/WebServices.htm
Project Sputnik
I've decided on the project name.
I remember a really awful track from Sigue Sigue Sputnik in 1986 called "21st Century Boy" which, as this project is to uplift the existing app into the 21st century, seems somewhat fitting. Here's a video of the group miming their way through the song on the UK's chart-TV programme Top Of The Pops so you too can see and hear how bad the song is.
Anyway. Project Sputnik it is.
I remember a really awful track from Sigue Sigue Sputnik in 1986 called "21st Century Boy" which, as this project is to uplift the existing app into the 21st century, seems somewhat fitting. Here's a video of the group miming their way through the song on the UK's chart-TV programme Top Of The Pops so you too can see and hear how bad the song is.
Anyway. Project Sputnik it is.
Overriding base form control events
This is something that's bugged me for a while, and each time I do this I hit the same problem before the "Oh Yeah!" moment occurs and I remember what I need to do. This is clearly just a problem in my head; something that isn't intuitive for me in someway.
Inherited forms in a WinForms application : overriding the base form's control events so that the base form's event code is not executed, just the code in the derived form.
It's really very simple and I don't know why I struggle with this every time, but I do. So this Blog entry is an Aide Memoire for me.
1. On the base form, select the control in the form designer and make sure the Modifier is set to Protected
2. On the base form, in the code window, mark the event handler as protected void ...
protected virtual void button1_Click( object sender, EventArgs e)
{
MessageBox .Show( "Hello" );
}
3. On the derived form, open the designer and double-click the button to add the button1_Click event code
4. Change the new event to protected override void ...
protected override void button1_Click( object sender, EventArgs e)
{
MessageBox .Show( "overridden" );
}
5. In the derived form's designer code, you can see that the derived form has subscribed to the Click event again. This means that the code in the derived form's _click event will get run twice - once when the base form click event calls it, and once when the derived form calls it. The fix is to remove the this.button1.Click += new System.EventHandler(this.button1_Click); line
6. If you need to run the code in the base class, you can do this:
base .button1_Click(sender, e);
Inherited forms in a WinForms application : overriding the base form's control events so that the base form's event code is not executed, just the code in the derived form.
It's really very simple and I don't know why I struggle with this every time, but I do. So this Blog entry is an Aide Memoire for me.
1. On the base form, select the control in the form designer and make sure the Modifier is set to Protected
2. On the base form, in the code window, mark the event handler as protected void ...
protected virtual void button1_Click( object sender, EventArgs e)
{
MessageBox .Show( "Hello" );
}
3. On the derived form, open the designer and double-click the button to add the button1_Click event code
4. Change the new event to protected override void ...
protected override void button1_Click( object sender, EventArgs e)
{
MessageBox .Show( "overridden" );
}
5. In the derived form's designer code, you can see that the derived form has subscribed to the Click event again. This means that the code in the derived form's _click event will get run twice - once when the base form click event calls it, and once when the derived form calls it. The fix is to remove the this.button1.Click += new System.EventHandler(this.button1_Click); line
6. If you need to run the code in the base class, you can do this:
base .button1_Click(sender, e);
Tuesday, 23 April 2013
Step 1
The current application is single user and was originally a VB6 application, so it makes sense that it uses a Microsoft Access database.
Not very 21st century though, huh?
The new version absolutely must use Microsoft SQL Server - there's no doubt in my mind about it, so to keep costs down I propose using SQL Express 2008 R2 to develop against.
Step 1 will be to download and install SQL Express, create a database with the same (or similar) data structure as the current database, and finally get some data into it.
The way I see it is that the starting point should be to port the existing application to use SQL Express rather than Access with no (obvious, or as little as possible) functional changes to the application resulting in a working product on SQL Express with the existing data. As time ticks by and the project progresses I will still need to use the existing application to run my business, and so the data will grow and change and I do not want to have any porting issues come switch-over day.
Anyway that's my rationale. So lets begin!
I downloaded SQL Express 2008 R2 With Tools from Microsoft and followed the installation procedure giving a named instance of SQLExpress and selecting Mixed Mode for authentication. Once that was done I fired up Management Studio and logged in to check things out.
So far so good.
Next was to port over the existing database from Microsoft Access. To do this I opened the existing database in Access and used the Uplift Wizard
I entered the settings for the new SQL Express installation and the new database name ...
... selected ALL tables ...
... accepted the default options ...
... selected "No application changes." as I want to manage the code changes myself when porting the current application to SQL Express ...
... and on the final step clicked Finish. The wizard threw up a few progress dialogues but nothing scary and in the end I was presented with an uplift report in Access.
I closed access and then used Management Studio to check the new database. It's all there! Excellent.
Step 1 is complete as I have a populated SQL database that I can use. On to step 2.
Not very 21st century though, huh?
The new version absolutely must use Microsoft SQL Server - there's no doubt in my mind about it, so to keep costs down I propose using SQL Express 2008 R2 to develop against.
Step 1 will be to download and install SQL Express, create a database with the same (or similar) data structure as the current database, and finally get some data into it.
The way I see it is that the starting point should be to port the existing application to use SQL Express rather than Access with no (obvious, or as little as possible) functional changes to the application resulting in a working product on SQL Express with the existing data. As time ticks by and the project progresses I will still need to use the existing application to run my business, and so the data will grow and change and I do not want to have any porting issues come switch-over day.
Anyway that's my rationale. So lets begin!
I downloaded SQL Express 2008 R2 With Tools from Microsoft and followed the installation procedure giving a named instance of SQLExpress and selecting Mixed Mode for authentication. Once that was done I fired up Management Studio and logged in to check things out.
So far so good.
Next was to port over the existing database from Microsoft Access. To do this I opened the existing database in Access and used the Uplift Wizard
... selected ALL tables ...
... accepted the default options ...
... selected "No application changes." as I want to manage the code changes myself when porting the current application to SQL Express ...
... and on the final step clicked Finish. The wizard threw up a few progress dialogues but nothing scary and in the end I was presented with an uplift report in Access.
I closed access and then used Management Studio to check the new database. It's all there! Excellent.
Step 1 is complete as I have a populated SQL database that I can use. On to step 2.
I wonder ...
So, I'm wondering how I should "keep" this Blog. Should I actively Blog as I attempt each step of the project, or should I complete the step, keep notes and then Blog about it when it has been completed?
I think it would probably be best to perform each task, keep notes and reasons behind decisions taken and then Blog about it when the step is done. Provided I keep the steps small enough that they don't take forever this should work well I think, and hide any embarrassing mistakes made on the way.
Yes, that seems sensible.
I think it would probably be best to perform each task, keep notes and reasons behind decisions taken and then Blog about it when the step is done. Provided I keep the steps small enough that they don't take forever this should work well I think, and hide any embarrassing mistakes made on the way.
Yes, that seems sensible.
RESTful web services
I've written SOAP WCF web services and I have heard the terms JSON (pronounced Jason) and RESTful services but I certainly have never written one or fully understand what they are. Wikipedia is always a good place to start, but a Google search of "rest web service example C#" came up with a very interesting first hit. I've spent some time today reading this article and looking at the code behind it.
REST Web Service using C# A walkthrough
Now I understand why Steve said I should use REST web services if I want my app to be usable on Android.
REST Web Service using C# A walkthrough
Now I understand why Steve said I should use REST web services if I want my app to be usable on Android.
Project Inception
Boredom. That is how it started. I was sitting at my PC when I realised that I didn't have anything to do, so my mind turned to my Office Manager tool. I put my thoughts on Facebook:
In the beginning ...
I'm not sure exactly where this Blog will go, where it will take me, or where it will end up. I think that ultimately this Blog will be just for me, privately, almost an Aide Memoire if you will. I'm not bothered about my posts being read, examined, commented on or dismissed, or about being any sort of internet author, commentator or superstar. That is not me at all.
I know why I wanted to start a Blog but explaining it rationally is difficult. I suppose I want a place where I can keep links to posts and web pages that I have found useful. I also want a place that I can put stuff that I want to remember. But I also need somewhere to dump my ideas. I guess this makes this blog the digital equivalent of the back of a fag packet.
There is a much more legitimate reason for the Blog though, and that is this:
I am going to re-write, re-work, or re-factor (whichever term is your preference) a software programme that I have written to help me manage my small business, and I intend to keep a diary of that journey. From soup to nuts, design to delivery, code to bug hunting. Just for my own benefit.
Maybe there will be more to this Blog than I first thought.
I know why I wanted to start a Blog but explaining it rationally is difficult. I suppose I want a place where I can keep links to posts and web pages that I have found useful. I also want a place that I can put stuff that I want to remember. But I also need somewhere to dump my ideas. I guess this makes this blog the digital equivalent of the back of a fag packet.
There is a much more legitimate reason for the Blog though, and that is this:
I am going to re-write, re-work, or re-factor (whichever term is your preference) a software programme that I have written to help me manage my small business, and I intend to keep a diary of that journey. From soup to nuts, design to delivery, code to bug hunting. Just for my own benefit.
Maybe there will be more to this Blog than I first thought.
Subscribe to:
Posts (Atom)