Forging a fresh architecture - Data store and data access

Data store

Its a requirement that the user and user profiles have a centralized store. I choose MS Sql server as storage system.

Remembering that simplicity is one of goals I'm trying to achieve I designed a data model very simple. Figure 1 shows the model.

Figure 1

Its also very simple to understand: each application have its own group of profiles. Each user is bound to one or more profiles. The user credentials are stored in tblUser and password filed contains a string already encrypted.

As you can see, I used some hints in table's name:

Tables that contains dynamic data are prefixed with tbl (meaning table). Tables that work as connections between tables are prefixed with rel (meaning relation). I also have a special prefix, ref (meaning reference), to tables that contains static data. In small systems, like this one, it is easy to control the data model and know where the information is stored. But when the system grows it gets much more difficult to remember where we had stored something. That is when the hints make sense.
Some special fields also have a prefix: fk. This means foreign key. And the rest of the name points to the table from where the key come (without table's prefix).

Try to leave some clues about your data model. It's always useful.

Ok. So I will consider the database done. Now I will focus on data access infrastructure.

Data access

I decided to use Linq to SQL as data access engine. Why I chose this data access method:

• It is very easy to use and maintain;
• It have a fluid and very friendly interface;
• It generates, automatically, all the mappings between tables and objects.

But this choice also brings me some drawbacks:

• The objects created during the mapping are not POCO (this means they are "fat" with things I don't need or don't want)
• It is slower than a simple data reader. Correcting: it is much slower;
• There is no easy way to isolate the data model. In general, the mapped objects are used as Data Transfer Objects (DTO) between layers and this will bring us to a design highly coupled.

In spite of these drawbacks I will keep with Linq To SQL (L2S) and try to find some work around to those issues. What I am planning:

• To solve the issues 1 and 3 I will use T4 templates and repository pattern to adapt mapped objects and decouple other layers from the data model;
• To address the issue 2 I will use the parallel extensions for Linq. Of course I don't expect to be as fast as the data reader but I hope to see some performance improvements specially in multi core computers.

So lets work:

Create L2S model:

As I mention before it's very easy to create a L2S model. It's just to add a new item to a project and choose LINQ to SQL Classes. I also chose to change the name to UserAndProfileModel.dbml. Picture 2 shows the dialog.

Figure 2 - Creating L2S model

Click Add button and it's done.
The empty model is created. Now is just to drag and drop the tables from the database model and all the mapping objects are created. Figure 3 shows the tables being selected and figure 4 shows the mapping classes over the drawing surface.

Figure 3 - Selecting tables to map

Figure 4 - Mapped classes

After all these steps I consider the data access layer done. The development process from the beginning to here was very simple and easy to understand. I hope to continue this way.

Keep in touch and... happy coding.

Download files

Forging a fresh architecture - The solution

After some research and discussions with my colleagues, I decided to develop a Brokered Authentication like described in Patterns and Practices article.

This piece of software will allow me to provide credential checking and profiling service very easily. To accomplish the other requirements I will also develop a small client based on a MVP pattern that can be used by all kind of applications.

The overview of the solution is displayed below (click to see a larger image):

Here comes a quick explanation about the modules (I will discuss in more detail every module):

1. UserAndProfileDataStore
   It is the database where user credentials and profiles are stored.
2. DataAccess
   This project will implement the LinqToSQL infrastructure that will be the main data access mode in the solution.
3. LinqRepository
   This project is where I will implement the repository pattern that will allow local applications  access data.
4. SmartUserAndProfile
   This project will host a web service that will expose the same functionality of LinqRepository but it will be available for distributed applications.
5. UserAndProfilesInterface
   This project will group all interfaces I will use in whole project.
6. UserAndProfilesLogic
   This project will handle all the logic necessary to the solution.
7. UserAndProfilesPresenters
   This presenters will standardize the interaction with the whole infrastructure so it will simplify the development of clients.

The drawing above was designed with VS2008 Distributed System Design + Microsoft Visual Studio Team System Architecture Edition Power Tools. This tool also create all projects that exists in the model. The result of the project generation is shown in the picture below:

Now that we already have the solution, lets start building all these artifacts and find how they will match.

Keep in touch and... happy coding.

Download files

Forging a fresh architecture - The challenge

Ok. I read something and talked with my colleagues and we found the features that are interesting to implement in this exercise.

So to give context I create a small history with these requirements. Here we have:

SmartEnterprise is a medium real estate firm that is redefining its I.T. strategies.
In this new strategy they defined that there will be a unified identity store. This repository will store user credentials and profiles for each application. Then there will be components that access this store to retrieve the user data. The components will be used in their intranet, windows application and extranet. All applications will execute credential checking in the same way
The way to use this new infrastructure should be as transparent as possible to the application developer's that will consume this data.

Ok. Lets summarize all this requirements to have a clear idea:

• Users and user profiles will have a centralized store;
• Credential checking will also be centralized;
• These data must be available to be consumed by several applications and the "flavors" can vary form a simple web app to a windows forms;
• The solution must include some kind of client code to help developers to integrate the authentication solution into their own application.

Assemble all this features is not a difficult task but this is the point!
I won't need spend time thinking how to solve the problem. I will spend the time identifying how to use all those new technologies to make the work even easier.

Next step: draw a solution with all this in mind and create a solution guide's to implement it. It may take some time.

Keep in touch and... happy coding.

Forging a refreshed architecture

In the past few months I have seeing a lot of new technologies :
Parallel Linq;
LinqToSql;
Unity;
T4.

And some design patterns also caught my attention:
Repository;
IoC;
MVP.

With all this in mind I started to think: how to put all this together to create a better software development experience?
So, from now on I will create a series of posts where I will exercise my view on all these subjects.

The next steps are to create some code to see how all these things work. But I don't want to recreate the sample codes that are bundled with this packages. I want to create something nearest the real world. But it can't be hard or I will lose focus in the technologies I am willing to understand. After a while thinking about what to code I decided to create a simple Authentication System. I will grab some more information and I will post more details about the features to be implemented.

Keep in touch and... happy coding.