Month: May 2014

Code one functionality you are going to implement from start to end. If the functionality means that you have to create a very big class from start to end, then do it. DO NOT debug or try to run the program before the functionality you desired is exactly implemented. The threshold is that your program will be able to produce the output you desired by the specified input. Doing debugging in the middle of your coding can distract your focus on implementing your functionality into real code. So just omit the debugging until the threshold is met.

You may also omit some of exception handling during this phase. In Java programming, this means that you have to catch every checked-exception and re-throw it as RuntimeException. This will ensure that any error inside your library will be brought up to the surface. Structured and well-formed exception handling takes time to do, so we can do it after the implementation is completed. But in a case that an exception handling is inclusive in the program flow, you must do the exception handling in this phase. It’s all on your judgement on how you design your program flow.

Overview

So I got a task in designing a scalable and modular Service Oriented application using JSON and WCF. I am designing a web service using WCF. The communication between the web service and the client will be using JSON. While the server is using .NET Framework, the client is using Android Java. I aim to design the service as modular as possible. For every web service request from the client, the server will return the response in some kind of “envelope”. The “envelope” contains the execution result, whether it is success or not, the text message from web service, and the attachment which may contains object of specific type as the result of the service call.

I want to develop the modularity in my service framework, where I can make the “envelope” object as generic object that accept any kind of attachment type. And I want to deserialize the JSON response from server in my Android directly into specified “envelope” and attachment type, so that I can use it fairly easy in my code.

I’ve been using Entity Framework since its introduction. Entity Framework (EF) is a powerful Object-Relational Mapping (ORM) framework for .NET Framework. I’ve been debating with my teammates whether EF is better than other ORM such as OpenAccess, which I believe is true, because EF provides the necessary feature to connect our program to the database, especially if you are using Microsoft products, SQL Server. In my thinking, why bother using custom ORM to connect to SQL Server while actually Microsoft, the creator of everything (well, not, only .NET Framework and SQL Server I’m talking about here) provided the powerful tools to support your needs. In fact, Microsoft fully support the EF and provides the latest features as their development (EF and SQL Server) (should) inline each other.

Ok, I’m not going to debate about which one is better. I am going to talk about Code First approach to build your model from scratch. This is the first time I am trying using Code First approach, while previously I always use Database First or Model First approach.

Ways to Model Your Database

Entity Framework has been evolving quite rapidly. In the newest version, I noticed they are now using DbContext class instead of the old ObjectContext. And the new generated classes (if you are generating the model from existing database), will be just Plain-Old-CLR-Objects (POCOs). In previous EF, all the model classes must be derived from EntityObject. This offers more flexibility in designing your model classes.

One other notable changes I found is that the entity framework do not require the resource file definition in the connection string anymore. This will offer more flexibility in porting your model into separate DLL library and reuse it wherever you want. I am going to explore this finding later.