Followers

My Visual Studio Achievements

Twitter

Monday, August 26, 2013

In one of my previous post related to interface usage, I had asked to explicitly implement interfaces always to achieve the principle of "Program to interface not to implementation". If we follow the advise you may enter into scenarios where you need to call an explicitly implemented method from another method. Another method can be interface method or normal method. Below is the situation.

In this scenario its good to call the second Foo method (parameterized) from the first one. But if you try to simply call it, you will end up in compilation error. Also you cannot do it using this keyword even though the method resides in same class. So what should we do?

If you really studied the theory behind the explicit interface implementation before coming into the programing field, you would have known this scenario. But still there are people who needs google to tackle this situation. The solution is to cast this object to IMyInterface and call the method. Below is the code.

Pros

Cons

Anyway I had modified the sample I got from the above link and uploaded. It can be downloaded from my sky drive by clicking on the below icon.

Multiple post back

This approach works as follows

There will be 1 post back for each file and one posting for the entities.If there are 8 records, there will be separate 8 post backs for files and one posting for the entities.

Each file will be posted separately. It returns the file id ie an reference to the server side where its saved. (If its saved in SQL Server or other database the primary key)

Associate that id to the row to be saved using jQuery / javascript

Post back the rows (entities) and when its saved in the server side, the row can be linked to the uploaded file. (If its in database use the foreign key relation)

Need to use iFrame to do posting of file input.

Pros

Data size limitation in http post back is resolved.

Cons

There are chances that the file upload succeeds and the subsequent record saving didn't success. This will result in orphan files which needs to be cleared as maintenance task.

Chunking

This involves separate reading mechanism or ActiveX controls to send files in chunks. This is useful if you need to transfer really big files. After completing each file the server side id needs to be updated to the new records and save after all file uploads.

We are planning to go with the second approach because we are not sure about the size of the files we need to upload. If the size of the expected files is small we can go with the first approach. So decide yourselves based on your scenario.

Monday, August 12, 2013

How to package classes into logical groups and physical containers is always a difficult thing to decide in software engineering. Package is used as it is in Java but when it comes to .Net world, its assemblies. In .Net , the .net framework is packaged in such a way that the core classes and interfaces are packed in one assembly and framework details are in different assemblies. In such a scenario one namespace may appear in multiple assemblies. the namespace in core assembly contains base classes and interfaces where the same namespace in different or track assemblies contain implementations.

Basically we can package by feature or package by layer. In an address book application, if we follow package by feature, add,edit, delete operation related classes ie CRUD classes will be in a single assembly and the reporting related classes will reside in different assembly. There will be 2 data access classes one for add, edit operations which falls to first assembly and another for accessing reporting related data access falls to second assembly.

Package by layer scenario ie horizontal packaging, package all the UI classes to one assembly, business logic to another assembly and data access classes to third assembly.

My recommendations on .Net assembly packaging

To be frank these are my observations on how to group classes into namespaces and how to split namespaces into assemblies. I didn't get any concrete answer from google on this topic. All were discussing about merits and demerits of different approaches and asking the developer to decide one method. So this recommendations are subject to change as my experience grows.

General

Follow the other design best practices such as SOLID, GOF patterns properly.

Keep in mind that software is created to change in next version.

Always group the classes into namespaces which are logical groups.

Give meaningful names to namespaces and assemblies. Reading a 100 page document about namespaces and its descriptions may not be practical when project grows more than 100 developers and 75% of them are freshers.

A bad assembly dependency graph is as wrong as bad code.

Small apps - team size below 10 and working in same location

Never go for multiple assemblies but must have different namespaces.

Separate creation of classes to factories.

When you feel you app is growing beyond initial estimated side create new assemblies as follows.

Medium size apps - team size 10 - 30 and working in same location.

Aim should be less no of assemblies so that the application will be fast.

If you feel that you may need to support getting a different presentation technology separate the UI namespace into a different assembly

Keep your core classes and interfaces in single assembly.

Have the default implementations in different assembly where the namespace will be same for the core and its default implementation.

If the default data access is through SQL Server and if we want to give XML data storage support, have xml data access class in a separate assembly and change the dependency creation. AddressBookXMLData.dll{Joymons.AddressBook.DL}

Big applications - team size more than 30 or working from remote locations.

Aim should be to have maximum isolation.

Let each track in the application have its on core for business and data access along with default implementations for all.

One assembly should contain one namespace. Name of the assembly should be same as the namespace.

Principles

Like other software engineering principles such as SOLID principle, packaging has also got principles. This will help the developers to package their classes to assemblies in a better way.

Tuesday, August 6, 2013

First time in my 8 years software engineering career, I took a session to public audience. The event was the monthly user meeting of Kerala Microsoft User Group K-MUG community. There were 3 another useful sessions which were about ASP.Net Web API, CDN via Azure and Using Fiddler.

It was a wonderful experience talking to the audience who comes from different backgrounds and different knowledge levels. Even though everyone uses DSL in one or another form, it was little difficult to make them understand that they are using DSL in their day to day life.

I started by comparing the software engineering with civil engineering in terms of requirement changes during project execution and as a solution to that introduced DSL concept. After explaining the concept along with 2 types internal and external DSL, I moved to using DSL concept in .Net applications. Explained what are the criteria we should consider before selecting a DSL and selected PowerShell as DSL script for a sample.

The sample was the same which I explained in one of my previous post. Explained where the DSL comes into picture in that simple salary calculation sample and showed how the reference to the PowerShell runtime is added.

I believe everyone got the idea of DSL but not the exact idea how they can implement in their project. Feel free to contact me on using DSL in your projects.