Architecture

Natural Key vs. Surrogate Key - Userid in Social Networks

Anatoly Lubarsky — Fri, 30 May 2008 13:36:00 GMT

All of us (almost) are the members of different social networks: Facebook, Bebo, Myspace, Hi5, etc. We ARE users. User is a real entity - a real person.

One of the problems is the ability to identify a user in a unique way across the internet.

There are 2 approaches to identify entity - both inherited from Relational database model.

Natural Key

Natural Key - a key which has logical reference to (or the same as) already existing unique entity attribute(s). The key has to identify a real entity whose existence can be verified. The most common example is person national ID number, which identifies national passport (?) in a unique way. However the ideal candidate for the persons natural key would be some fictional Global Universe ID. For social networks the best candidate so far is users EMAIL address since:

Email address is unique.
Email identifies a user in a unique way across all common social networks. The same email represents the same user in Facebook, Bebo, Myspace, etc.

The problem: usually email address cannot be shared once this or another social network decides to open its platform and share the user data due to privacy issues. For example email address is not accessible within Facebook API. The second issue is that actually the same user can have several mail addresses, which makes it less trivial to identify the user. Should we use a combination of all user emails to be able to perform identification in a unique way or just use the primary email address ?

Surrogate Key

Surrogate Key - a generated key which is not related to the entity attributes. Usually integer (INT or BIGINT, sometimes GUID). For example my userid on facebook is 500491268 and on bebo - 5282127447.

"Because the surrogate key is completely unrelated to the data of the row to which it is attached, the key is disassociated from that row. Disassociated keys are unnatural to the application's world, resulting in an additional level of indirection from which to audit."

As we can see the surrogate key is not unique across the internet. We get real problem when social networks (and their competitors) open their platforms to 3rd parties and decide to share the data. In order to identify the user in a unique way we need to scale the surrogate key to include another surrogate key which identifies the platform, but it remains still impossible to associate the same user on different platforms.

Conclusion

Recently we can see how different social networks are trying to win and dominate the social network space by trying to develop Connect Schemas in order to make connect more sites and applications and make them use their surrogate key to identify users. Recent examples are: Facebook Connect and Google Friend Connect.

I think this approach will not survive in the long run. The solution is the creation of something like Global Universe ID which identifies a person in the universe, globally and historically unique and shareable. LOL

Business Entity in Component-Oriented Architecture

Anatoly Lubarsky — Sat, 03 Mar 2007 07:01:00 GMT

Intro

So, what is Entity, anyway ? Many folks know they should program using components but smaller part is able to define what Business Entity is up to or can distinguish between Entity and other types of Application components for example Infrastructure Components or Logging Components or User.

Definition

Start from the Use Case. Then translate the Use Case to the Business Process (What customer is generally gonna do here and there using our Application). After scetching a bunch of Business Processes we finally can define Business Entities:

Business Entity is an independent role in a Business Process.

If you can define an independent role for it - it is Entity (for example Order vs. OrderItem in ProcessOrder business process).

Characteristics

Business Entities Provide stateful programmatic access to business data and (in some designs) related functionality.
Business Entity is passed as I/O parameter of business processes.

Thus - Entities can be serializable, to persist the current state of the entities. For example, applications may need to store entity data on a local disk, in a desktop database if the application is working offline, or in a Message Queuing message or travel via HTTP and Remoting.

Business Entity IS NOT

Infrastructure Component. All functionality that stands outside Use Cases is implemented in Infrastructure Components. Don't mix Business Entities with Infrastructure Components.
- SMTP, FTP, etc protocols implementation configuration/process/helper classes - are NOT Business Entities.
- Logging components classes. This can be implemented as Logging Configuration, Logging Data Access, etc - are NOT Business Entities. Logging is a bit tricky. For example if you want to audit Business Entity behaviour - need to translate Business Entity into Logging Component before you write to Log. This is because in this case Logging Component is actually a time-stamped copy of some Business Entity component stored in some Logging storage.
User profile component - is not Business Entity. Anyone who logins and has preferences - is NOT a Business Entity. User Profile could be implemented as Customer, Employee, User, etc. Thus - Authentication and Authorization related components are not related to Business Processing.

Entities do NOT

Access the database. All database access is provided by the associated Data Access Logic Component. Rule of Thumb - each Entity will have exactly one Data Access component per single data storage.
Initiate any kind of transaction. Transactions are initiated by the application or business process that is using the business entities. Actually this means that Business Entity does not implement any kind of functionality associated with Business Logic.

Entity Schema

Business entities can be built from data that has complex schemas. Single Entity can be implemented via muliple classes and collections. For example, OrderEntity is formed from Order, Product, OrderItem classes formatted and related to each other.

Enterprise Library DAAB: AddParameter vs. AddInParameter

Anatoly Lubarsky — Sat, 25 Mar 2006 20:39:00 GMT

I'm playing a bit with Entlib. now. Let's say I'm using it a lot actually :). Speaking of Data Access Block in Enterprise Library I'm coming to conclusion that it is not productive to use AddInParameter construction in Database object because:

It does not support parameter size causing ADO.NET pass the max allowed for the specified type.
There is no support for parameter InOut direction (aka AddInOutParameter ?) which I find very useful lately.

I'm going to use AddParameter instead of AddInParameter, despite that it is a bit less readable. Like so:

db.AddParameter(dbCommand,
    "@ProductId",
    DbType.Int32,
    4,
    ParameterDirection.InputOutput,
    true,
    0,
    0,
    null,
    DataRowVersion.Default,
    review.ProductId);

Design Guidelines: Generic Type Parameters

Anatoly Lubarsky — Mon, 05 Dec 2005 02:55:00 GMT

Brad Abrams talks about Framework Design Guidelines on Names of Generic Type Parameters.

"Generics are a major new feature of the .NET Framework 2.0. The feature introduces a new kind of identifier called type parameter. The following guidelines describe naming conventions related to naming such type parameters."

Enjoy

Core Coding Guidelines from Microsoft

Anatoly Lubarsky — Fri, 28 Jan 2005 01:34:00 GMT

Internal Microsoft basic coding guidelines. Provided by brada. My favorites:

"Tab characters (\0x09) should not be used in code. All indentation should be done with 4 space characters."

"Do use a single space after a comma between function arguments."

It is still very basic but interesting and one can follow the evolution of those since .net release back then in 2002. Despite the fact that I hate guidelines, sometimes (very rarely) it helps. My secret opinion though is that indentation should be done with 3 spaces. Ok, 4 spaces for americans among you. Enjoy :)

Smart Client Architecture Guide

Anatoly Lubarsky — Sun, 01 Aug 2004 04:22:00 GMT

You can download Smart Client Architecture Guide. [via eugeniop]

Fewer Assemblies better

Anatoly Lubarsky — Fri, 07 May 2004 02:32:00 GMT

As I thought - bigger assemblies are better than lots of small assemblies. Brada explains why. My word - keep max 3 per application.