Valdis Iljuconoks : Design

Calling a service from Windows Phone application reactively

valdis.iljuconoks — Wed, 20 Jun 2012 06:36:59 GMT

If you are creating connected Windows Phone application then most probably have noticed that mostly interface what Visual Studio (VS) generates for you in client proxy class is event-based async pattern.

For instance we have defined service (usually this is WCF implementation) method:

public class AtmFinderService : IAtmFinderService       
{       
    public ServiceResponse FindNearby(double latitude, double longitude)       
    {       
        ...       
    }

Generating the client proxy class we can see that VS generated event based approach, when we do have an incredible opportunity to use DoSomethingAsync() method in our favor and then try to catch event which is raised immediately after operation has been completed.

Using this method and event code does look pretty much readable (we will touch body of the event handler later on as well).

proxy.FindNearbyCompleted += (sender, args) =>      
                                 {       
                                     // do something       
                                 };

Suppose if you are sharing the proxy class (for instance, as static member of your service façade). Then for sure you will need a mechanism how you can unsubscribe from the event after method has been executed successfully. More info on subscribing and unsubscribing to the events here - http://msdn.microsoft.com/en-us/library/ms366768.aspx.

So, what we can do is to define event handler and store the reference to the body in class field or member. We can define variable as delegate:

EventHandler<FindNearbyCompletedEventArgs> delg = delegate(object sender, FindNearbyCompletedEventArgs args)       
                                                      {       
                                                          // do something       
                                                      };

or we can define to store as EventHandler:

var delg = new EventHandler<FindNearbyCompletedEventArgs>((sender, args) =>       
                                                              {       
                                                                  // do something       
                                                              });

Then I figured out that the most easiest way to subscribe only once per call is to unsubscribe first and then subscribe:

proxy.FindNearbyCompleted -= delg;      
proxy.FindNearbyCompleted += delg;

When next time method will be executed event handler added from previous call will be removed first, and then added new one.

Then we can proceed with the actual service method call. So the complete code is:

var delg = new EventHandler<FindNearbyCompletedEventArgs>((sender, args) =>       
                                                              {       
                                                                  // do something       
                                                              });       
      
proxy.FindNearbyCompleted -= delg;       
proxy.FindNearbyCompleted += delg;       
      
proxy.FindNearbyAsync(location.Latitude, location.Longitude);

This is more or less everything you need to call service method from Windows Phone in async event-based pattern.

One more note about event handler body. Usually there is requirement to execute event handler on the Dispatcher if that updates something in user interface from another thread (that may happen if event handler is called later on).

var delg = new EventHandler<FindNearbyCompletedEventArgs>((sender, args) =>       
            {       
                if (Deployment.Current.Dispatcher.CheckAccess())       
                {       
                    Deployment.Current.Dispatcher.BeginInvoke(/* method */);       
                    return;       
                }       
      
                // do something       
            });

Here comes another problem that we need to call the same event handler body only within the Dispatcher context.

Easiest way to implement this requirement would be to implement additional method as event handler and then perform dispatcher check there and if call requires dispatcher context, invoke the same method once more within dispatcher context.

So we are implementing the event handler method first.

private void ProxyOnFindNearbyCompleted(object sender, FindNearbyCompletedEventArgs args)       
{       
    if (!Deployment.Current.Dispatcher.CheckAccess())       
    {       
        Deployment.Current.Dispatcher.BeginInvoke(new Action<object, FindNearbyCompletedEventArgs>(ProxyOnFindNearbyCompleted),       
                                                  sender,       
                                                  args);       
        return;       
    }       
      
    // do something       
}

And then the original code that attaches the event handler and calls the method remains almost the same:

proxy.FindNearbyCompleted -= ProxyOnFindNearbyCompleted;      
proxy.FindNearbyCompleted += ProxyOnFindNearbyCompleted;       
      
proxy.FindNearbyAsync(location.Latitude, location.Longitude);

However for me this all seems already converting into unreadable spagetti-like code set.

There is a more elegant way to accomplish this. I’m going to use Reactive Extensions for Windows Phone – Microsoft.Phone.Reactive. Library is coming with Windows Phone SDK.

At first we are defining observable from the event-based async pattern.

var completedObservable = Microsoft.Phone.Reactive.Observable.FromEvent<FindNearbyCompletedEventArgs>(       
    ev => proxy.FindNearbyCompleted += ev,       
    ev => proxy.FindNearbyCompleted -= ev);

Those two arguments for FromEvent() method is used to add event handler and to remove event handler for FindNearbyCompleted event. This is also an elegant way how to write code that subscribes to the event only once.

When observable has been created we are able to subscribe to to the event and provide handler to execute when event is raised.

completedObservable.Subscribe(result =>      
                                  {       
                                      // do something       
                                  });

The complete code looks like following:

var completedObservable = Observable.FromEvent<FindNearbyCompletedEventArgs>(      
    ev => proxy.FindNearbyCompleted += ev,      
    ev => proxy.FindNearbyCompleted -= ev);      
      
completedObservable.Subscribe(result =>      
                                  {      
                                      // do something      
                                  });      
      
proxy.FindNearbyAsync(location.Latitude, location.Longitude);

Pretty straight forward and what’s important – code is readable and understandable.

One more thing, if you require to run event handler on Dispatcher thread, than that’s far more easier than previous implementation with direct checking dispatcher access. You just have to tell reactive extensions that you need to observe events on dispatcher thread rather than on current context.

completedObservable.ObserveOnDispatcher().Subscribe(result =>      
                                                        {       
                                                            // do something       
                                                        });

In summary, code gets reduced, more readable and understandable.

Hope this helps!

When you need something stronger..

valdis.iljuconoks — Mon, 04 Jun 2012 22:22:51 GMT

Have you seen code fragment like this? I mean there are lot of interfaces that provide stringly-typed access to some of the internals of the entity. This particular code fragment could be seen a lot in EPiServer Relate+ product code samples.

var instance = new SampleType();         
instance.SetAttributeValue("ThisIsTheAttribute", value);

Accessing something that’s not pretty strong enough could be very easy and fast. Not a big deal – just type in attribute name and value.

Here goes why I don’t like interfaces like these:

When you will margin for a grammar error when typing attribute name – that could be discovered only during runtime.
You cannot use static code analysis tools. Like to search for all attribute usages.
You cannot use some of the refactoring tools –> like rename attribute name.
You can easily change type of the attribute and forget about code that uses that, effect –> runtime error.
Use cannot leverage all the power of Visual Studio (for instance to provide Intellisense over available attributes)

So as we see – there a lot more troubles around stringly-typed interfaces than benefit you gain.

We are going to change this in this blog post.

First of all we would need to define client API – that’s how we are going to use our strongly-typed interface to talk to your stringly friend.

I would like to see following things in client API:

There should be an object that would describe structure of the stringly-typed object. Like enumerating all the properties that we would like to have access to. I would call it – a metadata object.
There should be an easy way to convert stringly-typed object into this metadata object.
Metadata object will be used to talk to stringly-typed object via strongly-typed metadata object.

I would see client API and some code snippets as following:

var instance = new SampleType();         
var metadata = instance.AsAttributeExtendable<SampleAttributeMetadata>();         
metadata.SampleAttribute = value;

Metadata class could be described like this:

public class SampleAttributeMetadata         
{         
    public object SampleAttribute { get; set; }         
}

This metadata object is just an object that will provide us strongly-typed access later on.

First things first.

To convert stringly-typed object into some more meaningful instance we would need something “attachable” to original object. Extension methods will come to rescue today.

So we are able to write static method that will attach to original object and behave as instance method for that object. No matter which is your original object (for sake of integrity I’ll use EPiServer Relate+ ‘IAttributeExtendableEntity’ interface).

public static T AsAttributeExtendable<T>(this IAttributeExtendableEntity entity) where T : class, new()

This means that we are defining extension method for objects that implement ‘IAttributeExtendableEntity’ interface (those are almost all entities in EPiServer Relate+). This ‘IAttributeExtendableEntity’ interface provides stringly-typed access to attributes that you can set or get.

Generic type parameter T – that will be our metadata object class.

Next –> we need to somehow take a control over the metadata object that as given away to the caller of the extension method defined earlier.

For this reason one of the most easiest way to accomplish this is to use some sort of interceptor infrastructure. What interceptor does? Idea behind the interceptor is that client who got back the metadata object thinks (an result object really looks alike) that object that was given back is of defined metadata object type. And so do all code analysis tools (therefore Intellisense is available) and compiler as well.

Actually using interceptors we are giving back fake metadata object that has lot of injections in it in order to for us to gain control over the further client’s interaction with the object.

One of my favorite library to accomplish this is ‘Castle project’. Pretty easy to use and straightforward.

So what we need is to create a fake metadata object with our injections to control what’s going after we return the object. In order to get this done we need to define our interceptor and return a class proxy created using this interceptor.

So the code for AsAttributeExtendable() method is like this:

public static T AsAttributeExtendable<T>(this IAttributeExtendableEntity entity) where T : class, new()           
{           
    if (entity == null)           
    {           
        throw new ArgumentNullException("entity");           
    }           
          
    var interceptor = new DefaultInterceptor<T>(entity);           
    var gen = new ProxyGenerator();           
    var options = new ProxyGenerationOptions(new ProxyGenerationHook());           
          
    var proxy = gen.CreateClassProxy<T>(options, interceptor);           
    return proxy;           
}

UPDATE:

NB! Lessons learned! Actually it’s not quite a good idea to create proxy generator, generation hook and class proxy on each request. Just got through support ticket on memory leak and huge memory consumption. Which ended-up with lot of dynamically generated assemblies loaded into application domain and lot other stuff.

A better solution is reuse ‘ProxyGenerator’ class instance and cache generated class proxies for particular types.

First of all need to define static instance of the proxy generator class and store where cached class proxy instances will be stored.

private static readonly ProxyGenerator gen = new ProxyGenerator();         
private static readonly ProxyGenerationOptions options = new ProxyGenerationOptions(new ProxyGenerationHook());         
private static readonly ConditionalWeakTable<IAttributeExtendableEntity, object> table =         
    new ConditionalWeakTable<IAttributeExtendableEntity, object>();

Then we can implement updated method to generate class proxy for particular class of particular type:

public static T AsAttributeExtendable<T>(this IAttributeExtendableEntity entity) where T : class, new()        
{        
    if (entity == null)        
    {        
        throw new ArgumentNullException("entity");        
    }        
        
    object classProxyCached;        
        
    // try to find already created class proxy from the cache        
    // this is required to increase speed a bit and not to create new class proxy for the same class more than once        
    table.TryGetValue(entity, out classProxyCached);        
        
    if (classProxyCached == null)        
    {        
        classProxyCached = GenerateClassProxy<T>(entity);        
        table.Add(entity, classProxyCached);        
    }        
        
    return classProxyCached as T;        
}

And proxy generation method remains almost unchanged:

private static T GenerateClassProxy<T>(IAttributeExtendableEntity entity) where T : class, new()         
{         
    var interceptor = new DefaultInterceptor<T>(entity);         
    var options = new ProxyGenerationOptions(new ProxyGenerationHook());         
    var proxy = gen.CreateClassProxy<T>(options, interceptor);         
        
    return proxy;         
}

Let’s spilt them up into smaller pieces:

DefaultInterceptor – this is the class that will contain the logic that will be called if client code will try to access something that we marked as interceptable in class ProxyGenerationHook class.
ProxyGenerationHook – class that describes what is going to be intercepted and what should be passed to the underlying intercepted object.

Let’s look at hook class (it should implement ‘IProxyGenerationHook’ interface):

public class ProxyGenerationHook : IProxyGenerationHook         
{         
    public void MethodsInspected()         
    {         
    }         
        
    public void NonProxyableMemberNotification(Type type, MemberInfo memberInfo)         
    {         
        throw new InvalidOperationException(string.Format("Property named '{0}' for type '{1}' is not marked as virtual.",         
                                                          memberInfo.GetProperty().Name,         
                                                          type));         
    }         
        
    public bool ShouldInterceptMethod(Type type, MethodInfo methodInfo)         
    {         
        // we are interested only in properties for now         
        return methodInfo.Name.StartsWith("get_", StringComparison.Ordinal)         
               || methodInfo.Name.StartsWith("set_", StringComparison.Ordinal);         
    }         
}

This hook is instructing Castle dynamic proxy generation engine that interceptor will intercept *only* properties (setters and getters). Btw, properties are compiled into methods anyway. This particular hook logic of course can be modified and adjusted to meet precise requirements.

Otherwise (method NonProxyableMemberNotification()) will be called if some of the metadata object members could not be intercepted. This is particular useful for error checking. NB! What Castle actually does is that behind the scene another object is created that *inherits* from our defined metadata object. Therefore members (in this case only properties) must be marked as virtual – because Castle tries to override those with its own logic. If that fails - NonProxyableMemberNotification() method is called.

Let’s look into DefaultInterceptor code (it must implement ‘IInterceptor’ interface):

public class DefaultInterceptor<T> : IInterceptor         
{         
    public void Intercept(IInvocation invocation)         
    {

It only has single method – Intercept(). The most interesting part of interception is parameter – invocation, that gives us lot of info about method client code is calling.

Usually code within Intercept method starts with checking what kind of method client is calling, like:

if (invocation.Method.Name.StartsWith("get_", StringComparison.InvariantCultureIgnoreCase))         
{

if (invocation.Method.Name.StartsWith("set_", StringComparison.InvariantCultureIgnoreCase))         
{

Just to check either user is getting value from the property or setting value for the property.

Actual interception code really depends on situation and requirements but usually some of the properties of IInvocation class are used:

invocation.Method – is the method that is going to be called.
invocation.Arguments – is list of arguments passed the call of the method.
invocation.ReturnValue – set the result of the interception.

Trick for interceptors – if you want to interrupt interception and return immediately to the caller – just return from the method. Otherwise you’ll need to call invocation.Proceed() method that will call next interception or ultimately will call target object’s method.

And within the interception code you can convert called method (getter or setter for properties) into call to stringly-typed object (Substring(4) will remove ‘get_’ or ‘set_’ from the name of the called method):

Entity.SetAttributeValue(invocation.Method.Name.Substring(4), invocation.Arguments[0]);

or for retrieving something and return that value to the caller’s code:

var methodInfo = Entity.GetType().GetMethod("GetAttributeValue");         
var genericMethod = methodInfo.MakeGenericMethod(invocation.Method.ReturnType);         
invocation.ReturnValue = genericMethod.Invoke(Entity, new object[] { invocation.Method.Name.Substring(4) });

Sequence diagram of final call stack could look something like this:

Sample project where Castle interceptors are used to provide strongly-typed access over EPiServer Relate+ entities can be found there.

Hope this helps!

TPL (Task Parallel Library) prezentācijas source code.

valdis.iljuconoks — Mon, 07 May 2012 19:54:36 GMT

Pēc Latvijas Universitātes auditorijas lūgumu izvietoju prezentācijas demo source code. Pieejams šeit.

Ja rodas kādi jautājumi, iebildumi vai filozofiskas pārdomas – noteikti gaidu jūsu feedback: valdis punkts iljuconoks at dotnet punkts lv.

Happy parallelisming!

Schedule

valdis.iljuconoks — Wed, 18 Apr 2012 21:09:00 GMT

Kā izrādās, tad aprīļa pašas beigas un maija mēnesis izvērties par diezgan aizņemtu laika posmu. Katrā ziņā, var noķert mani kaut kur tur

Aprīlis 2012:

2012.04.26: Transporta un Sakaru Institūts:

18:15 – 19:15 “MSF & Agile”

19:15 – 19:45 “TFS 2012 Overview (Dev ‘11)”.

Maijs 2012:

2012.05.07: Latvijas Universitāte:

18:15 – 19:15 “Parallel Computing in Visual Studio 2010”

2012.05.08: Vidzemes Augstskola:

10:00 – 10:55 “Asp.Net MVC”

11:00 – 11:55 “Funkcionālā programmēšana - F#”

12:00 – 12:55 “Visual Studio 2012 - What's new?”

13:00 – 13:55 “Requirements Management in TFS”

2012.05.14: Latvijas Universitāte:

18:15 – 19:15 “Funkcionālā programmēšana - F#“

2012.05.17: Ventspils Augstskola:

11:00 – 11:45 “Designing Software Architecture in VS 2010”

12:45 – 13:30 “C# 3.0 & C# 4.0”

13:40 – 14:25 “MSF & Agile”

14:35 – 15:20 “Requirements Management in TFS”

2012.05.21: Latvijas Universitāte:

18:15 – 19:15 “C# 5.0 – async”

2012.05.28: Latvijas Universitāte:

18:15 – 19:15 “Ievads jQuery“

Cerams, ka noderēs!

Divi vienādi “Jāņi”

valdis.iljuconoks — Mon, 12 Sep 2011 20:48:00 GMT

Hash kods ir interesanta padarīšana un parasti šo metodi izmanto, lai aprēķinātu objekta hash kodu kādā no hash funkcijas balstītām datu struktūrām, piemēram, HashSet<T> vai Dictionary<K, V> vai tam līdzīgās struktūrās. Hash kods šajās datu struktūrās tiek izmantots, lai optimizētu meklēšanas operāciju.

However ar hash kodiem jābūt uzmanīgiem.

Parasti kā rāda pieredze viens no code-smells ir struktūru (struct) pielietošana. Viss ir labi, bet ir jāsaprot tās side-effekti neskatoties uz to performances (struktūras parasti glabājas tur par stekā pretstatā references tipiem, kuri atrodas heap’ā) un kind-of maintainability (struktūras parasti pēc definīcijas ir immutable) benefitiem.

Anyway, pieņemsim, ka ir sekojoša klase, kas implementēta kā struktūra:

public struct Client

    public string Name;

    public string Surname;

    public string Code;

    public DateTime BirthDate;

Pieņemsim, ka ir definētas pilnīgi dažādas klienta entity instances:

var client = new Client

                     Name = "Janis",

                     Surname = "Berzins",

                     BirthDate = new DateTime(1999, 1, 1),

                     Code = "1234567890"

};

var client2 = new Client

                      Name = "Janis",

                      Surname = "Kalnins",

                      BirthDate = new DateTime(1978, 4, 1),

                      Code = "0987654321"

};

Pārbaudām hash kodu šī abām instancēm:

Console.WriteLine(client.GetHashCode().ToString());

Console.WriteLine(client2.GetHashCode().ToString());

Iznākums nav diez ko iepriecinošs :)

Hash kodam ir jāapmierina pavisam tikai 3 noteikumi:

Ja divi objekti ir vienādi (== operators), tad tiem ir jāģenerē vienādi hash kodi. Pretējā gadījumā hash kods nevar tikt izmantots, lai tos meklētu dažādās datu kopās.
X.GetHashCode() objektam X ir jābūt neatkarīgam no instances stāvokļa. Tas nozīmē, ka pēc X objekta izveides neskatoties kādas tik metodes nav izsauktas, objektam ir jāatgriež viens un tas pats hash kods. Tas arī nodrošina, ka objekts vienmēr tiek ievietots pareizajā vietā (bucket).
Hash kodam jāģenerējas izmantojot visu pieejamo integer spektru. Šāda veida algoritms nodrošina pietiekamu datu struktūras optimizēšanu.

Kas patiesībā notiek abu “Jāņu” hash koda ģenerācijas laikā var izlasīt Microsoft .Net Framework source koda anotācijā (reāls izvilkums no platformas source code):

/*=================================GetHashCode==================================
**Action: Our algorithm for returning the hashcode is a little bit complex.  We look
**        for the first non-static field and get it's hashcode.  If the type has no
**        non-static fields, we return the hashcode of the type.  We can't take the
**        hashcode of a static member because if that member is of the same type as
**        the original type, we'll end up in an infinite loop.
**Returns: The hashcode for the type.
**Arguments: None.
**Exceptions: None.
==============================================================================*/

Tātad patiesībā hash koda ģenerācija “Jāņu” gadījumā notiek pēc pirmā non-static lauka šajā struktūrā – Name. Savukārt šis uzstādījums apgalvo, ka visiem “Jāņiem” būs vienāds hash kods, kas arī apliecinās dzīvē.

Kā jau visam šajā pasaulē cilvēks ir atradis skaidrojumu, tā arī šai Microsoft platformas parādībai. Platformas dizaineri ir System.ValueType objektā ieguldījuši visas zināšanas, kas viņiem bija un ir, lai uzģenerētu hash kodu tipam, par kuru viņiem nebija ne mazākās nojausmas.

Ja jūsu definētais tips nepiedalās nekādās datu struktūrās, kur nepieciešams definēt atslēgas, tad hash koda ģenerācija parasti nav nepieciešama vispār. Hash koda ģenerācijas pārrakstīšana retāk ir nepieciešama references tipa objektiem, kur hash koda ģenerācijai tiek izmantots iekšējais objekta instances identifikators.

Cerams, ka noderēs!

“Konstantīns” mēdz būt tricky

valdis.iljuconoks — Sat, 20 Aug 2011 20:53:00 GMT

Kā jau mēs visi zinām, labā prakse ir visādas konstantes, nemainīgas vērtības un citu lietderīgu informāciju sistēmās definēt vienreiz un izmantot atkārtoti. Tomēr daudzās vietās mēs redzam apmēram šādu kodu:

/// <summary>

/// Service for policy related operations.

/// </summary>

[ServiceBehavior(Namespace = “http://service-provider.com/project/service/”)]

public class PolicyService : IPolicyService

vai arī teiksim kaut kādu aptuveni šādu koda fragmentu:

if (customer.Age > 78)

    RaiseError("MaximumCustomerAge");

Trūkums šādai konstantes “iešūšanai” kodā ir izmaiņu process. Nekad nevar zināt, kurās vietās un kādos nosacījumos tiek pielietotas šīs maģiskās vērtības. Šādu vērtība nomaiņa dažreiz prasa full-text search, ir nestabila un negarantē viennozīmīgus rezultātus – ka visās vietās, kodā maģiskā vērtība ir nomainīta sekmīgi.

Šīs problēmas risinājums ir izmantot konstantes. Galvenais ieguvums šādai pieejai, protams, ir izmaiņu lokalizācija un sava veida garantija, ka veicot izmaiņas tikai konstantes vērtībā, tā tiek ņemta vērā visās sistēmas sadaļās, kur tā tiek pielietota.

Bet… šeit ir viens catch…

.Net platformā eksistē divu veidu konstantes:

Kompilācijas laika konstantes.
Runtime laika konstantes.

Kompilācijas laika konstantes tiek definētas ar keyword const un tiek izmantotas kompilācijas laikā. Savukārt, runtime konstantes tiek definētas ar keyword readonly, tās tiek inicializētas klases konstruktora laikā un tās nav iespējams mainīt pēc klases uzkonstruēšanas jeb instances izveidošanas.

Galvenais catch konstantes pielietošanā ir kompilācijas laika konstantes nepareiza pielietošana. Kompilācijas laika konstantes vērtība performances nolūkos tiek ievietota izsaukuma vietā. Savukārt runtime laika konstantes tiek inicializētas klases konstruktora laikā un vietas, kurās tā tiek izmantota, uztur referenci uz šo vērtību.

Piemēram, augstāk redzamo koda fragmentu, kas pārbauda klienta vecumu aizvietosim ar kompilācijas laika konstanti:

private const int MaxAge = 78;

private static void Main(string[] args)

    var customer = new Customer { Age = 55 };

    if (customer.Age > MaxAge)

        RaiseError("MaximumCustomerAge");

Aplūkojot kompilēto kodu redzams, ka if() pārbaudē nav vairs reference uz MaxAge mainīgo, bet ir jau iekompilēta konkrēta vērtība – 78.

IL:

L_0018: ldc.i4.s 0x4e

Dekompilēts C#:

if (customer.Age > 0x4e) 
  
{ 
  
    RaiseError("MaximumCustomerAge"); 
  
}

Savukārt pārveidojot kompilācijas laika konstanti par runtime laika konstanti:

private static const readonly int MaxAge = 78;

private static void Main(string[] args)

    var customer = new Customer { Age = 55 };

    if (customer.Age > MaxAge)

        RaiseError("MaximumCustomerAge");

Redzams, ka kompilators liek referenci uz mainīgo nevis tā vērtību:

L_0018: ldsfld int32 ConstantsDemo.Program::MaxAge

Kāds tad varētu būt potenciālais risks kompilācijas laika konstantes pielietojumos?

Patiesībā interesantākās problēmas sākas software patch un citu ielāpu deployment un smoke testing laikā, kad atklājas, ka vecās bibliotēkas, kuras tomēr izmantoja konstantes no moduļa, kas atjaunots kopā ar patch, nez kāpēc izmanto vēl vecās konstantes vērtības un par nelaimi vēl piedalās kaut kādos matemātiskos vai finansiālos aprēķinos.

Iemesls kāpēc varētu vajadzēt izmantot kompilācijas laika konstantes nevis runtime laika konstantes – ir to pielietojums atribūtu izmantošanā. Diemžēl jeb par laimi atribūti var saturēt tikai kompilācijas laikā zināmas konstantes, kā atribūtu īpašību vērtības.

Nav iespējams dekorēt target site ar atribūtu, kurš definēts izmantojot runtime laika konstanti (notiks kompilatora kļūda – “An attribute argument must be a constant expression, typeof expression or array creation expression of an attribute parameter type”):

[CustomAttribute(ThisIsMagicString)]

internal class Program

    private static readonly string ThisIsMagicString = "magic-string";

Pēdējā laikā secinājām, ka konstantes ĻOTI ērti ir definēt WCF servera servisa pusē, regulējot visu servisu root vārdu telpu:

/// <summary>

/// Service for policy related operations.

/// </summary>

[ServiceBehavior(Namespace = Constants.RootNamespace + “/PolicyService”)]

public class PolicyService : IPolicyService

Abiem konstantes veidiem ir savi pielietojumi, tikai jāzina side-effekti katram no tiem.

Cerams, ka noderēs!

Happy coding…

Code review classics

valdis.iljuconoks — Sat, 13 Aug 2011 21:09:49 GMT

Ir pagājis jau krietns laiciņš kopš veicu code-review laiku pa laikam. Sākumā bija doma pierakstīt katru atrasto lietu un apskatīt to sīkāk, bet ar laiku entuziasms noplaka nedaudz, bet nu gala rezultātā esmu tomēr apkopojis septiņas visizplatītākās kļūdas vai nianses, kas atkārtojas no code-review uz code-review.

Lielākā daļa ir neatkarīgi no cilvēkiem, projektiem un pat tehnoloģijām, kuras pielieto kādā konkrētajā projektā vai sistēmā. Šeit ir saraksts ir izplatītākajām issues, kas tik atrastas kārtējā code review procesā:

Naming convention
Unused namespaces
this qualifier
StyleCop un FxCop violations
Complex conditional statements
File name does not match type name
Unused local scope variables

Naming convention. Šis ir viens no visizplatītākajiem pārkāpumiem vai issues, kas tiek atrasts kārtējā izejas koda pārskata procedūrā. Lai arī kāda būtu konkrētā projekta norunātā naming konvencija, tā vienmēr tiek pārkāpta. Vai nu tie ir nepareizi izvēlēti klases nosaukumi (piemēram, ir projekti, kas mēģina izvairīties no “*Manager.cs” vai “*Manager.vb” failiem, kas savukārt var norādīt uz SRP principa pārkāpumu).

Nav nozīmes, kurā līmenī ir pārkāpums: vai tas tiek darīts kodā, vai HTML’ā vai pat datubāzē. Jebkura pārkāpuma detektēšanai ir nepieciešams ieviest kādus automātiskos rīkus un paņēmienus. Pāris idejas:

Koda re-formatēšanas operācija notiek katru nakti – būvējuma laikā. Tādā veidā izstrādātājiem nav iespējas veikt tīšu/netīšu nosacījumu un norunu pārkāpumu. Tās visas tiek “salabotas” būvējuma laikā.
Izmantot kādu koda analīzes rīku, kas meklē naming convetion pārkāpumus (piemēram, FxCop var pastāstīt, ka projektā nav pieņemts, ka metodes nosaukumus satur apakšvītru simbolu “_”).
Interesants piegājiens bija vienam no maniem kolēģiem. Datu bāzes objektu naming convention () pārbaude notiek ar speciālu šim nolūkam izveidot vaicājumu, kas apstaigā SQL servera sistēmas viewus un tabulas un apskatās vai, piemēram, visi primary atslēgas objekti sākas ar “Pk_” simbolu virkni. Ja kāds no noteikumiem tiek pārkāpts šo vaicājumi ātri var iedarbināt būvējuma laikā un jebkurš pārkāpums tiks fiksēts ar būvējumu, kas izgāžas.

Unused namespaces. It kā jau nekas traģisks un kādu nenormālo impaktu tas nerada, bet tomēr šķiet ka te kaut kas nav īsti pareizi un pārskatāmi.

this qualifier. Arī šis pārkāpums īsti neko ļaunu nenodara, bet ļoti bieži kodā ir redzams, ka “this.” tiek over-pielietots. tas nozīmē, ka jebkurā vietā klases pirmkodā, kur notiek griešanās pie pašreizējās klases vērtībām, mainīgajiem vai kādiem citiem klases slotiem, izsaukums tiek uzsākts ar “this.”. Viss ir forši un uzreiz pēc punkta “.” parādās IntelliSense ar visām iespējamajām kombinācijām un izvēlēm pašreizējās klases kontekstā, bet IntelliSense izvēlnei var izmantot arī citus paņēmienus.

StyleCop un FxCop violations. Tas protams ir atkarīgs no projekta, bet ir projekti, kuros mēģina ievērot gan StyleCop, gan arī Code Analysis (a.k.a FxCop) ietikumus un nosacījumus. Ļoti bieži saskaros ar problēmu, ka code-review laikā daudzi no ieteikumiem tiek pārkāpti. Izrādās, ka šie noteikumi ir tikai uz papīra un to ievērošana ir tikai formāls pasākums. Lai tā nebūtu, ieteicams šos noteikumus “ieforsēt” jeb padarīt neiespējamu tos pārkāpt. Viens no klasiskajiem variantiem ir ieslēgt TFS checkin politikas, ja tiek izmantots Team Foundation Server platforma, kur uzglabāt izejas kodu sistēmai vai projektam. Otrs variants ir vēl visas Code Analysis pārbaudes pārslēgt uz “Error” režīmu, kas kļūst par būvējuma grāvējiem situācijās, kad kāds ir pārkāpis šos noteikumus. Ļoti palīdz :)

Complex conditional statements. Šis bija viens no Clean Code Cheat Sheet norādījumiem, kas parāda, ka visticamāk šis nosacījums, kas ietverts “if” statement iekavās nav pārāk saprotams un uztverams, kur nu vēl modificējams vai refaktorējams bez kļūdām.

Šāda veida issues viens no variantiem, ka varētu noķert ar koda metrikām, bet visātrāk tos ievērot un salabot laikam jau ir manuālajos code-review procesos.

if (parameter.Count > 0 && Client.MustApply &&

    (Client.Gender == HumanGender.Male || Client.Age > 50) &&

    ((selectedProgram.Id == 45 && chosedRisk.Id == 1945) || IsFreeProgram.Checked))

    // do some magic...

File name does not match type name. Arī nav baigās problēmas dēļ šī, bet ļoti izplatība problēma. Zināmas grūtības varētu rasties, kad sistēmas izejas kods tiek pētīts un analizēts bez VS object browser vai kādu citu sakarīgu programmu, kas skatās uz loģisko sistēmas saturu nevis fizisko. Piemēram, bieži rodas situācijas, kad ražošanas vides serverī, kuram pieeja iedota tikai uz 30 minūtēm, jo redziet kāds sistēmas administrators iedomājies, ka vairāk laika programmatūras piegādātājiem reāli kritiskā situācijās problēmas risinājumam vairāk laika nebūs nepieciešams, ir jāpārlūko failu sistēmas saturs un tikai vadoties pēc failu nosaukumiem ir jāsaprot kurā klasē ir jāveic izmaiņas. Pēc tam var izrādīties, ka klase izejas kodā nav tāda pati, kāds bijis faila nosaukums, kas bijis cēlos kādai problēmai.

Šīs problēmas risinājums pieejams vienā no VS papildinājumiem – Resharper:

Unused local scope variables. Šis arī neko ļaunu pārāk nevar nodarīt klasiskajās situācijās, kad klase satur pa kādam liekam mainīgajam. Problēmas varētu sākties situācijās, kad klase satur kādu sen nelietotu mainīgo, kas degradē objekta veidošanas vai inicializēšanas procesam nepieciešamo laika sprīdi, ja izrādās, ka šis “nelietotais” mainīgais ir palicis pāri no kāda code-review/code-refactoring sesijas un aizņem patiešām ievērojami laika sprīdi, jo iespējams, ka inicializē vai izmanto kādu sen aizmirstu time-consuming operāciju.

Šādā veidā mēs uz ražošanas vides atklājām vienu interesantu memory-leak problēmu.

Arī par šādam lietām vienu no populārākajiem VS paplašinājumiem – Resharper – var iemācīt bļaustīties pamatīgāk nekā pēc noklusējuma uzstādījumiem tas drīkst darīt.

Happy coding!

Cerams, ka noderēs!

Dependency Inversion - pēdējais on S.O.L.I.D.

valdis.iljuconoks — Sun, 10 Jul 2011 21:49:00 GMT

Oriģinālliteratūra: “Principle refers to a specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details”.

Šis princips definē sekojošus noteikumus jeb likumus, kas būtu jāievēro:

Augstākā līmeņa moduļiem nevajadzētu būt atkarīgiem no zemāka līmeņa moduļiem. Abiem moduļiem jābūt atkarīgiem no zināmām abstrakcijām.
Abstrakcijām nav jābūt atkarīgām no detaļām. Detaļām jāzina par abstrakcijām.

Modernās sistēmās arhitektūra un klašu dizains ir veidots tā, lai augstāka līmeņa komponentes izmantotu zemāka līmeņa komponentes sava darba jeb problēmu apgabala risināšanai. Tas nodrošina zemāka līmeņa komponentēm ļauj būt atkārtoti izmantojamām, kas nozīmē, ka zemāka līmeņa komponentes jāveido tā, lai tām nebūtu informācijas un atkarība no augstāka līmeņa komponentēm jeb komponentes piedāvātās funkcionalitātes klientiem.

Savukārt šeit saskaramies ar nākamo problēmu, proti, kurš rūpēsies par augstākā līmeņa komponenšu atkārtotas izmantošanas iespējām? Ja augstākā līmeņa komponente ir tiešā veidā atkarīga no zemākā līmeņa komponentēs, tad ievērojami samazina augstākā līmeņa komponentes pielietošanu citās vietas un citās situācijās.

Šī principa galvenais mērķis ir atdalīt augstāka līmeņa komponenti no zināšanām par zemāka līmeņa komponentes detaļām un uzbūvi – tādā veidā radot labvēlīgus apstākļus augstākā līmeņa komponenti izmantot citās vietās vai situācijās.

Reālā dzīvē šī veida atdalīšana izskatās ļoti vienkārši un apmēram tiek realizēta sekojošā veidā:

pirmkārt šāda veida atdalīšana sistēmās notiek fiziski – augstākā un zemākā līmeņa komponentes tiek novietotas dažādos moduļos vai bibliotēkās
zemākā līmeņa komponentes uzvedība vai piedāvātā funkcionalitāte tiek reprezentēta kā interfeiss un parasti atrodas vai nu tajā pašā bibliotēkā, kur atrodas augstākā līmeņa komponente vai arī tiek izdalīta speciāla bibliotēka speciāli paredzēta šāda veida abstrakciju uzglabāšanai
lai zemākā līmeņa komponente piedāvātu augstākā līmeņa komponentei nepieciešamo funkcionalitāti, tai ir jābūt atkarīgai no augstākā līmeņa komponentes, ja interfeiss ir definēts tajā modulī vai arī uz kādu speciāli izdalītu bibliotēku
tādā veida atkarības saites tiek pagrieztas otrādāk jeb invertētas – augstākā līmeņa komponente vairs nav atkarīga no zemākā līmeņa komponentes.

Vēlāk jau runtime laikā tiek izmantoti daudzi dažādi patterni (Plugin, Dependency Injection, Service Locator), kādā veidā platforma vai sistēma piemeklē zemāka līmeņa komponentes nepieciešamajām augstākā līmeņa komponentēm.

Šim nolūkam, protams, var rakstīt savu ietvaru (angl. framework), bet .Net pasaulē jau eksistē daudz dažādas sistēmas un bibliotēkas, kas piedāvā izstrādātājiem jau gatavus risinājumus. Populārākās no dažām tikai: SpringFramework.Net, Microsoft Extensibility Framework (MEF), Enterprise Library Unity Block, StructureMap.

Citiem vārdiem sakot, Dependency Inversion Prnciple dažkārt jauc ar Inverse of Control principu, kas arī nav nejaušība. Abi šie principi eksistē un runā gandrīz par vienu un to pašu – kādā veidā efektīvāk atdalīt komponentes savā starpā, lai mazinātos nepieciešamās neatkarības saites un vienkāršotu kopējo sistēmas arhitektūru.

Šoreiz iztiksim bez nevienas koda rindiņas :)

Bet vispārīgi, ceru, ka princips tapa skaidrāks. Ja mēs redzam, ka lietām būtu jābūt nesaistītām, savstarpēji neatkarīgākām, tad šādos gadījumos starp abām komponentēm, starp kurām ir izcēlies kariņš un notiek vainīgo galvas skalošana, tiek definēts interfeiss, kas regulē abas puses: to, ko augstākā līmeņa komponente sagaida no zemākā līmeņa komponentes un ko zemākā līmeņa komponente var piedāvāt augstākā līmeņa komponentei.

Kā jau to pieminēju “Interface Segragation Principle” rakstā, interfeiss šeit nav domāts tikai ar klašu interfeisu. Interfeiss var būt arī cita klase, kas dod iespēju saviem klientiem iegūt vajadzīgo joy, piedāvājot tieši to funkcionalitāti, kas nepieciešama augstākā līmeņa darbībai.

Cerams, ka noderēs!

Pārējie raksti SOLID sērijā:

Liekam pinktu uz “I” no apvienības S.O.L.I.D.

valdis.iljuconoks — Sat, 09 Jul 2011 21:18:00 GMT

Oriģinālliteratūra: “The Interface Segregation Principle (ISP) states that clients should not be forced to depend on methods they do not use.”

Šo principu ir pavisam vienkārši interpretēt un viegli ievērot: klientam, kas lieto komponenti, kuras autori esam mēs, nedrīkstam jeb nebūtu vēlams “uzspiest” vairāk informācijas nekā viņam (komponentes klientam) tas būtu nepieciešams.

Šī principa kontekstā – interfeiss nav domāts tikai klašu interfeiss (keyword interface), ko kāds implementē vai realizē. Šajā principā runa ir arī par klasēm, kurām ir klienti jeb lietotāji.

Uzskatāmākais piemērs nāk no “System” vārdu telpas – System.Web.Security.MembershipProvider.

namespace System.Web.Security

    public abstract class MembershipProvider : ProviderBase

        public abstract bool EnablePasswordRetrieval { get; }

        public abstract bool EnablePasswordReset { get; }

        public abstract bool RequiresQuestionAndAnswer { get; }

        public abstract string ApplicationName { get; set; }

        public abstract int MaxInvalidPasswordAttempts { get; }

        public abstract int PasswordAttemptWindow { get; }

        public abstract bool RequiresUniqueEmail { get; }

        public abstract MembershipPasswordFormat PasswordFormat { get; }

        public abstract int MinRequiredPasswordLength { get; }

        public abstract int MinRequiredNonAlphanumericCharacters { get; }

        public abstract string PasswordStrengthRegularExpression { get; }

        public abstract bool ChangePassword(string username, string oldPassword, string newPassword);

        public abstract bool ChangePasswordQuestionAndAnswer(string username,

                                                             string password,

                                                             string newPasswordQuestion,

                                                             string newPasswordAnswer);

        public abstract MembershipUser CreateUser(string username,

                                                  string password,

                                                  string email,

                                                  string passwordQuestion,

                                                  string passwordAnswer,

                                                  bool isApproved,

                                                  object providerUserKey,

                                                  out MembershipCreateStatus status);

        public abstract bool DeleteUser(string username, bool deleteAllRelatedData);

        public abstract MembershipUserCollection FindUsersByEmail(string emailToMatch,

                                                                  int pageIndex,

                                                                  int pageSize,

                                                                  out int totalRecords);

        public abstract MembershipUserCollection FindUsersByName(string usernameToMatch,

                                                                 int pageIndex,

                                                                 int pageSize,

                                                                 out int totalRecords);

        public abstract MembershipUserCollection GetAllUsers(int pageIndex,

                                                             int pageSize,

                                                             out int totalRecords);

        public abstract int GetNumberOfUsersOnline();

        public abstract string GetPassword(string username, string answer);

        public abstract MembershipUser GetUser(object providerUserKey, bool userIsOnline);

        public abstract MembershipUser GetUser(string username, bool userIsOnline);

        public abstract string GetUserNameByEmail(string email);

        public abstract string ResetPassword(string username, string answer);

        public abstract bool UnlockUser(string userName);

        public abstract void UpdateUser(MembershipUser user);

        public abstract bool ValidateUser(string username, string password);

        protected virtual byte[] DecryptPassword(byte[] encodedPassword);

        protected virtual byte[] EncryptPassword(byte[] password);

        protected virtual byte[] EncryptPassword(byte[] password,

                                                 MembershipPasswordCompatibilityMode legacyPasswordCompatibilityMode);

        protected virtual void OnValidatingPassword(ValidatePasswordEventArgs e);

        public event MembershipValidatePasswordEventHandler ValidatingPassword;

Jau aplūkojot šo abstraktās klases saturu un nosaukumu, skaidrs, ka šis interfeiss ir nedaudz pa “resnu” un prasās uz dizaina sesiju, kurā visticamāk, ka tiktu radīti citi – mazāki interfeisi, kas piedāvātu konkrētu funkcionalitāti, kas fokusēts un kādu konkrētu problēmu domeinu. Piemēram, vai paroles kriptēšana un atkriptēšana tiešām ir MembershipProvider atbildība?

Vēl pēc kā var mēģināt identificēt ISP pārkāpumu ir #region apgabali kodā. Princips ir: ja kodā tiek pielietots reģions, tas visticamāk nozīmē, ka konkrētais koda fragments visticamāk, ka jāpārbīda uz kādu citu vietu (parasti tā ir jauna metode vai pat jauna komponente).

Pāris ieteikumi, kā var mēģināt ievērot ISP ikdienas API dizainēšanas darba procesā:

veidojiet mazus interfeisus, paturiet tikai nepieciešamo
ļaujiet savas komponentes klientiem nodefinēt vēlamo un nepieciešamo interfeisu
pārveidojiet lielus interfeisus mazākos interfeisos, no kuriem katrs piedāvā kādu šauru fokusētu funkcionalitāti.

Internetā uzgāju interesantu bildi, kas ļoti precīzi raksturo ISP pārkāpumu:

Cerams, ka noderēs!

Pārējie raksti SOLID sērijā:

Šodien nākamais darba kārtībā ir “L” no apvienības S.O.L.I.D.

valdis.iljuconoks — Thu, 07 Jul 2011 22:16:00 GMT

Orģinālliteratūra: Liskov Substitution Principle (LSP) states that subtypes must be substitutable for their base types.

“L” burts patiesībā nāk no šī programmatūras dizaina principa autores – Barbara Liskov! Nez kāpēc, bet man pēc nosaukuma šķiet, ka autoram bija jābūt vīrietim :) Varbūt vienkārši pieradums, ka parasti visādas teorijas IT industrijā izdomā un pieraksta stiprā dzimuma pārstāvji.

Barbas oriģinālais teksts: “What is wanted here is something like the following substitution property: If for each object o₁ of type S there is an object o₂ of type T such that for all programs P deﬁned in terms of T, the behavior of P is unchanged when o₁ is substituted for o₂ then S is a subtype of T.”

Pirmajā piegājienā nedaudz grūti aptvert šo principu un izprast, bet tas kļūst skaidrs iedomājoties un saprotot šī principa pārkāpumu un sekas, kas izriet no šī pārkāpuma.

Klasiskais dizaina pieejas pārkāpums: ja kāda metode izmanto kādu bāzes klasi, lai ar to operētu, un šai metodei ir nepieciešams zināt arī par visiem bāzes klases bērniem jeb mantotajām klasēm, tad šī metode pārkāpj LSP principu.

Piemēram, ja mums ir šāda veida klašu hierarhija:

Un neliela metode, kas piedalās kaut kādā lielākā procesā, lai konkrētā momentā piedāvātu reitingu konkrētam personu tipam:

public decimal GetRatio(Person person)

    if (person is Customer)

        return 1.2M;

    if (person is Employee)

        return 0.9M;

    return 1.0M;

Principiāli šī metode pārkāpj Open-Closed principu, par ko rakstīju iepriekš, t.i., ja sistēmā parādās jauna tipa persona vai arī kāds personas tips tiek pasludināts par obsolete, jāmaina ir eksistējošs / strādājošs kods nevis jāpievieno jauns koda fragments vai jādzēš eksistējošs, kas nodrošina nepieciešamo funkcionalitāti.

Bieži šī principa ietvaros runā par ISA veida attiecībām starp bāzes un bērna (mantoto) klasi. ISA tulkojams kā IS-SUBSTITUTABLE-FOR. Balstoties uz šo attiecību modeli starp bāzes un bērna klasēm, pārējā pasaule (citi koda fragmenti, kas izmanto šīs klases) pieņem lēmumu, ka operējot ar bāzes klasi metodei nav jāzina, ka iespējams patiesībā operē ar kādu no bērna klasēm un līdz ar to arī zarojas metodes loģika vai pat pilnībā loģika mainās.

Vēl klasisks piemērs LSP pārkāpumam ir šāds koda fragments:

public class Person

    public virtual string GetAffiliationName()

        return string.Empty;

public class Customer : Person

    public override string GetAffiliationName()

        return "Nordea Client";

public class Employee : Person

    public override string GetAffiliationName()

        throw new NotImplementedException();

Ja sistēmā eksistēs kāda metode, kas darbojas ar Person klasi un visticamāk, ka saņem to kā metodes argumentu, tad kādā momentā saņemt patiesībā Employee objektu jeb klases instanci, metodes izsaukums beigsies ar kļūdas situāciju.

Šīs metodes autors pieņēmis lēmumu, ka jebkurai personai sistēmā ir iespējams iegūt atlaižu piederības grupas nosaukumu un autoram nav bijusi informācija par to, ka sistēmā persona, kas patiesībā ir kādas firmas darbinieks, piederības grupas nosaukuma iegūšanu neatbalsta principiāli, jo darbiniekiem netiek atbalstītās atlaižu piederības grupas.

No šī principa var mācīties vienu pamatnosacījumu par programmatūras modeļa modelēšanu – modelis nekad nevar būt pareizs, ja tiek aplūkots un verificēts izolācijā no reāliem šī modeļa klientiem jeb lietotājiem – citām komponentēm vai koda fragmentiem.

In genral Liskov princips ir paplašinājums Open-Closed principam, kas pievēršas programmatūras dizaina problēmām tieši klašu mantošanas scenārijos, un stāsta par to, ka bērna klasei jeb klasei, kas mantojas no kādas bāzes klases, jāspēj pilnvērtīgi aizvietot bāzes klasi nemainot tās uzvedību.

Un vēl atradu internetā pietiekami sakarīgu motivējošu bildi, kas apraksta šo principu. Diez vai pielietosim Pekinas pīles recepti dzeltenajai pīlei, tikai tāpēc, ka tā peld un pēkšķ kā pīle :)

Cerams, ka noderēs!

Pārējie raksti SOLID sērijā:

EF .Include(“..”)

valdis.iljuconoks — Tue, 05 Jul 2011 22:43:30 GMT

Labas vakaras,

Kāds laiciņš nav nekas šeit rakstīts, jo vasara kā izrādās vienmēr ir viens no karstākajiem periodiem, kad pēkšņi daudzi ir atmodušies no ziemas un pavasara noguruma un sāk plānot darbus un bīdīt lielos plānus, kuri ir jāpabeidz līdz gada beigām, jo nez kāpēc izrādās, ka daudzu programmatūras izstrādes plānu ārējo “jūdžakmens” datumu vadībai parasti nenotrīc roka ielikt datumu, kas sākas ar “01.01.XXXX”. Gadu parasti piedomā klāt pēc tam ;)

Bet ne par to stāsts šoreiz. Raksts tapis saistībā ar nelielu datu bāzes struktūras izmaiņu veikšanu un Entity Framework datu modeļa tālākas piefrizēšanas, par cik datu piekļuve aplikācijā notiek ar EF palīdzību.

Daudzās vietās kodā, ja tas patiešām ir nepieciešams, redzam konstrukciju:

using (var ctx = new Entities())

    return ctx.Addresses.Include("Client").Select(e => e).ToList();

Vienkāršības labad pieņemsim, ka EF modelis mums ir pavisam vienkāršs:

LINQ izteiksme augstāk piemērota situācijās, kad EF konteksts vairs nav pieejams vai arī LazyLoading ir izslēgts, bet vēlāk pēc rezultātu iegūšanas ir nepieciešama kāda informācija no saistošās entītijas – piemēram, šajā gadījumā: meklējam adreses un katrai no adresēm pielādējam klāt arī informāciju par pašu klientu, kam šī adrese pieder, lai vēlāk kādā skatā vai citā vietā izmantotu klienta informāciju.

Kas notiek gadījumos, kad veicam pamatīgu DB refaktoringu un izdomājam, ka beigu beigās “Client” entītiju nesauc vairs par klientu, bet, piemēram, par “Customer” :)

Ok, veicam izmaiņas datu bāzē –> pārsaucam tabulas, visas references un saišu nosaukumus, etc. Pēc tam varam ķerties pie EF modeļa jeb loģiskā aplikācijas slāņa un veikt izmaiņas tur. Pārsaucam entītiju un protams arī visas saites uz citām entītijām.

Daudzas vietas kodā pēc izmaiņām noteikti nekompilēsies, jo, protams, tāds vai šāds tips netiks atrasts. Bet skatoties uz dažādām LINQ izteiksmēm ar .Include(“”) kompilācija norisināsies veiksmīgi, jo viss ir non-typed piegājienā.

Es labprāt pasapņotu par strongly-typed access dažādām metodēm un viena no tām ir ObjectSet<T>.Include(“”). Cik forši būtu, ja varētu uzrakstīt:

return ctx.Addresses.Include(e => e.Client).Select(e => e).ToList();

Vienā momentā apnika refaktorēt un pārdizainēt un nolēmu uzrakstīt paša spēkiem šādu metodi. Un šeit tā arī ir:

public static ObjectQuery<TEntity> Include<TEntity>(this ObjectSet<TEntity> objectSet,

                                                    Expression<Func<TEntity, object>> expression)

                                                    where TEntity : class

    if (expression == null)

        throw new ArgumentNullException("expression");

    var expressionBody = expression.Body;

    if (expressionBody.NodeType != ExpressionType.MemberAccess)

        throw new InvalidOperationException("Expression is not of `MemberAccess' type.");

    var memberExpression = (MemberExpression)expressionBody;

    return objectSet.Include(memberExpression.Member.Name);

Metode ir veidota kā paplašinājuma metode ObjectSet<T> objektam, kas nozīmē, ka vienīgā izmaiņa ir pašā Include() metodes argumentā (nu un, protams, arī using pievienošana, ja izmantošana ir citā vārdu telpā nekā paplašinājuma metode).

Protams, šī jaunā metode nepārliecinās, ka tas kas tiek padots argumentā tiešām ir navigācijas property kādai no entītijām un šāda veida izsaukums arī kompilēsies:

return ctx.Addresses.Include(e => e.Client.Name).Select(e => e).ToList();

Kaut gan runtime laikā saņemsim sejā paziņojumu par to, ka paši esam dumji :)

Cerams, ka noderēs!

Arhitektūras šablons

valdis.iljuconoks — Sat, 04 Dec 2010 21:01:36 GMT

Pēc klasikas jebkura sistēmai var izdalīt vismaz trīs slāņus. However vairāk vai mazāk ir iespējams izdalīt sekojošus apgabalus jeb slāņus:

Prezentācijas slānis.
Biznesa loģikas slānis.
Datu piekļuves slānis.
Platforma jeb Cross-Cutting.

Īpaši ar mākslinieciskām dotībām neesmu apveltīts, bet šāda bilde man pastāvīgi redzama pie sienas :)

Prezentācijas slānī parasti atrodas:

Web interfeiss. Lietotāja interfeisa tīmekļa aplikācijas izskatā. Šis punkts protams ļoti atkarīgs no sistēmas un produkta, bet jebkurā gadījumā vairums modernajām sistēmām ir vismaz viens lietotāja interfeiss balstīts uz tīmekļa tehnoloģijām.
Desktop interfeiss. Iespējams, ka eksistē arī kāds lietotāja interfeiss, kas ir balstīts uz Windows Formām vai WPF.
Publiskie servisi (web servisi). Pārsvarā eksistē sistēmā arī kaut kādi servisi, kas tiek izmantoti no ārpuses. Piemēram, dažāda veida servisu piegāde ārējām sistēmām jeb ārējiem biznesa loģikas patērētājiem.
Background (fona) servisi. Fonā parasti notiek arī kaut kādas aktivitātes, kur nav nepieciešams cilvēka pirksta pieskāriens. Ir dažāda veida servisi jeb procesi, kas notiek vai nu regulāri vai arī reaktīvi reaģējot uz kādu no notikumiem, kas notiek sistēmā. Notikumi parasti notiek biznesa objekta modelī (piemēram, apdrošināšanas polise beidzas – fona process ir atbildīgs par atbilstošā statusa uzstādīšanu).
Administrācijas vide. Caur kaut kādu UI sistēmas administratoriem jādod iespēju arī administrēt to biznesa sistēma un pārējos dažādos artefaktus, kas figurē sistēmā (piemēram, lietotājus vai klasifikatorus, etc.).
Kaut kas vēl custom specifisks konkrētajai sistēmai vai produktam. Dažāda veida tooļi, scripti vai kādi helper apgabali, kas bagātina un papildina kopējo sistēmas funkcionalitāti.

Par biznesa loģiku nav daudz ko stāstīt. Tur parasti atrodas biznesa loģika, dažādi “manageri” (kaut dzīvē bieži esmu redzējis, ka cilvēki ražo biznesa slānī tieši menedžerus, kas prot daudz ko un atbild par daudz ko, tomēr man uzskats ir ka, ka kopsummā ir sistēma jākonstruē tā, ka ir strikti nodalītas atbildības, katra klase atbild par kādu konkrētu biznesa procesa daļu, operāciju, funkcionalitāti vai atbildību), pārvaldnieki, biznesa procesu draiveri, servisu fasādes un kas vēl ne cits.

Savukārt ar datu piekļuves slāni parasti ir interesantas diskusijas. Un diskusijas parasti ir par to, vai speciāli ir nepieciešams izdalīt datu piekļuves slāni kā atsevišķu bibliotēku vai assembliju. Cik no pieredzes es varu spriest, izdalīt atsevišķu datu piekļuves slāni ir izdevīgi un nepieciešams gadījumos, kad sistēmai vai produktam ir jāatbalsta vairākas datu bāzes vadības sistēmas. Un izdevīgi to ir veidot tā, ka pārējā sistēmas daļa ir neatkarīga no datu bāzes vadības sistēmas izvēles un viss notiek noteiktā abstrakcijas līmenī.
Parasti, pielietojot modernās datu piekļuves tehnoloģijas ērti un organiski sanāk nedaudz sapludināt biznesa slāni ar datu piekļuves slāni un kontraktiem no platformas jeb cross-cutting slāņa, tādā veidā izdalot jaunu slāni – Data Contracts, kurš tāpat kā Cross-Cutting ir pieejams visiem slāņiem un komponentēm. Vienības no Data Contracts slāņa parasti kalpo kā saziņas līdzeklis un interfeiss komunikācijās starp dažādiem slāņiem un sistēmas komponentēm.

Platformā cilvēki parasti saliek visu pārējo, kas ir palicis pāri nesadalīts starp iepriekšējiem slāņiem. Tas gan ir stipri atkarīgs no sistēmas vai produkta, bet vairums situācijās jebkurā no sistēmām var izdalīt sekojošas sadaļas jeb komponentes, kas atrodas platformas slānī:

Logging. Žurnalizēšana un viss ar to saistītais (gan tehniskais žurnāls, gan arī biznesa), API, etc.
Caching. Kešatmiņas tehnoloģijas un pieejas izvēle arī brīžiem var radīt nelielas galvas sāpēs arhitektiem un inženieriem.
Configuration. Noteikti sistēmās ir kāda sadaļa, kurā uzglabājas dažāda veida konfigurācijas parametri un uzstādījumi. Brīžiem arī interesants jautājums, kā to visu saglabāt un padarīt pieejamu dažādiem slāņiem un komponentēm, kā rīkoties situācijās, kad mainās konfigurācijas uzstādījuma vērtība, vai vienmēr pārlasīt vērtību pie katras tās pieprasīšanas vai tomēr izvēlēties kādu no kešatmiņas risinājumiem? Arī šie jautājumi mēdz nomākt arhitektus.
Error Handling. Reti kura sistēma ir uzrakstīta bez nevienas kļūdas. Pareizi tā noķert un apstrādāt ir šī apakšmoduļa uzdevums.
Authentication un Authorization. Noteikti sistēmā būs nepieciešama dažāda veida drošības risinājumi. Diezgan bieži jaunieši jauc vietām šīs divas smalkās lietas.
Monitoring. Šī apakšmoduļa uzdevums ir sekot sistēmas veselības stāvoklim, aplūkojot un ziņojot par dažādiem problēmapgabaliem vai situācijām. Parasti šīs lietas tiek atstātas novārtā, bet patiesībā, ja jums iznāk strādāt pie kāda produkta, mēģiniet sev iestāstīt, ka jebkurai sistēmai ir jānodrošina kaut kāda veida diagnostikas iespējas un jālaiž ražošanā ar iestrādātiem speciāliem diagnostikas portiem vai interfeisiem, atvērtām iespējām noskaidrot, kas notiek sistēmā un vai nevajadzētu pievērst kāda sistēmadministratora uzmanību.
Localization. Parasti mūsdienās attālumam vairs nav nozīmes un nereti ir situācijas, kad indieši raksta kodu amerikāņiem, vai norvēģi ievieš savu sistēmu Zviedrijā, etc. Tā kā ar vien biežāk nākas domāt par lokalizāciju un sistēmas daudzvalodību. Šīs problēmas risināšanai tiek veidoti moduļi, kas ietilpst šajā komponentē.
Validation. Datu kontraktu satura pareizīguma pārbaude un verifikācija notiek parasti šajā komponentē. Tas, protams, ir stipri atkarīgs no sistēmas un produkta, bet parasti vairums sistēmas eksistē kāda veida datu validācija pirms tie nokļūst datu glabātuvē (parasti datu bāzē).

Šīs ir lietas un aspekti, kurus esmu saskatījis vairākās sistēmās, kurās man bijis tas gods piedalīties un palīdzēt cilvēkiem tikt galā ar uzdevumiem (parasti tos sauc par challanges :)).

Ja nu kādam sanāk darboties pie kādas sistēmas vai arī, ja kāds palūdz jums uzzīmēt kādu smuku bildi, kurai pēc biznesa īpašnieku domām būtu jāapraksta un uzskatāmi jārunā par kādas konkrētas sistēmas arhitektūru, tad iespējams, ka varētu noderēt šī layer diagramma, kas tika veidota pārzīmējot diagrammu, kas redzama nedaudz augstāk.

Kā jau mēs zinām, slāņu diagrammu var arī validēt un pārbaudīt pret reālo situāciju, kas ir risinājumā. Tā kā atliek tikai salikt pareizos projektus pareizajos slāņos un viens solis tuvāk nefiltrētajai gaišajai nākotnei ir sperts! :)

Nākamreiz mēģināsim ieskicēt, kāds ir modernais tehnoloģiju stack, kuras var pielietot šādas arhitektūras sistēmās.

Cerams, ka noderēs!

Šodienas gaviļnieks - “O” no S.O.L.I.D. apvienības

valdis.iljuconoks — Sun, 21 Nov 2010 06:52:00 GMT

Zinātniskā literatūra Open/Closed Principle raksturo šādi:

The Open/Closed Principle states that software entities (classes, modules, functions, etc.) should be open for extensions, but closed for modification.

Tātad par ko šis princips mums liek domāt? Sistēmas uzbūve un koda konstrukcijas ir jāveido tā, lai papildinājumus sistēmā varētu ērti ieviest un pielikt nemainot eksistējošo kodu, tādā veidā samazinot potenciālās kļūdas, kas varētu rasties pārējās sistēmas daļās vai komponentēs, kurās tiek izmantots kods, kuru nepieciešams būtu mainīt, ja sistēmai ir jānodrošina kāda papildus funkcionalitāte.

Šāda veida koda konstrukcijas var veidot balstoties uz abstrakcijām jeb nodalot bāzes funkcionalitāti jeb biznesa procesu no mainīgajām daļām, kurās potenciāli būtu jāievieš papildinājumi. Microsoft .Net platformā abstrakciju var realizēt ar pāris metodēm:

Klašu interfeisiem (class interface).
Bāzes abstraktajām klasēm (base abstract class).

Lai realizētu Open/Closed principu, var ņemt palīgā kādu no realizācijas metodēm:

Mantošana (inheritance) un vai šablona metodes (template method pattern). Šajā realizācijas metodē tiek veidota bāzes klase, kas apraksta metodes parametrus, nosaukumu un atgriežamo vērtību tipu. Jaunas uzvedības vai loģikas gadījumā ir jāveido jauna klase, kas mantojas no šīs bāzes klases un attiecīgi pārraksta konkrēto metodi ar jauno loģiku.
Parametri (parameters). Šis ir visvienkāršākais veids, kā nodrošināt O/C principu. Konkrētā loģika vai algoritms tiek papildināts un tā uzvedību regulē konkrēti parametri, kurus iespējams nodot algoritmam.
Stratēģijas (composition/strategy pattern). Stratēģijas metode dod iespēju veidot koda abstrakcijas tādā veidā, ka bāzes algoritms zina tikai sadarbības interfeisu ar kādu no komponentēm vai klasēm, kurā tiek realizēta nepieciešamā loģika. Bāzes algoritms neko nezin par konkrētās klases vai komponentes iekšējo uzbūvi un dizainu, tādā veidā panākot abstrakcijas līmeni, ka izmaiņas loģikā neievieš potenciālas jaunas problēmas vai kļūdas pārējās sistēmas daļās.

Risinājums, kādā veidā sistēmā notiek jaunas uzvedības pievienošana ir veidojot vienu vai vairāk klases, kas implementē nepieciešamo uzvedību vai loģiku. Ieguvums, ko sniedz Open/Closed princips ir, ka līdz šim par jaunām klasēm neviens sistēmas modulis nezin un potenciāli arī iespēja ieviest kādas jaunas kļūdas ir zemāka. Šīs mazās klases, kas sistēmai pienes jauno funkcionalitāti, realizē tikai nepieciešamo loģiku, kā rezultātā sistēmas veidošana seko arī Single Responsibility principam, ka klase ir paredzēta kāda konkrēta mērķa vai loģikas realizēšanai. O/C princips arī samazina if un switch valodas konstrukcijas, kas savukārt samazina koda uzbūves sarežģītību, testi paliek plakanāki, saprotamāki un pārskatāmāki.

Zemāk ir dots neliels triviāls piemērs, lai nodemonstrētu O/C principa ieviešanas mērķi. Piemērs ir balstīts uz ceļojuma apdrošināšanas polises klases bāzes. Pieņemsim, ka ceļojuma polises cena ir atkarīga no katra ceļotāja vecuma, nodarbošanās veida, kas plānots ir gala mērķī un dienu skaita, cik ilgi ir plānots būt uzrādītajā gala mērķī. Vienkāršības pēc cena nav atkarīga no valsts vai reģiona, uz kuru ir plānots doties. Klienta kods, kas veido ceļojuma polisi, pievieno personas un aprēķina prēmiju ir šāds:

var policy = new TravelPolicy

                     CoverDays = 10

};

policy.Persons.AddRange(new[]

                                new Person

                                        Name = "Jānis",

                                        Surname = "Bērziņš",

                                        Age = 41,

                                        ActivityType = ActivityType.Leisure

},

                                new Person

                                        Name = "Marija",

                                        Surname = "Bērziņa",

                                        Age = 43,

                                        ActivityType = ActivityType.Leisure

},

                                new Person

                                        Name = "Ansis",

                                        Surname = "Bērziņš",

                                        Age = 14,

                                        ActivityType = ActivityType.Sport

},

                                new Person

                                        Name = "Brigita",

                                        Surname = "Bērziņa",

                                        Age = 82,

                                        ActivityType = ActivityType.Leisure

});

Console.WriteLine(policy.CalculateTotalPremium());

Kods, kas rēķina prēmiju ceļojuma apdrošināšanas polisei:

public decimal CalculateTotalPremium()

    foreach (var person in Persons)

        if (person.Age <= 21 && person.ActivityType == ActivityType.Leisure)

            this.totalPremium += 2.5m * CoverDays;

        else if (person.Age <= 21 && person.ActivityType == ActivityType.Sport)

            this.totalPremium += 3.5m * CoverDays;

        else if (person.Age > 21 && person.Age <= 80

                 && person.ActivityType == ActivityType.Leisure)

            this.totalPremium += 5.5m * CoverDays;

        else if (person.Age > 21 && person.Age <= 80

                 && person.ActivityType == ActivityType.Sport)

            this.totalPremium += 7.5m * CoverDays;

        else if (person.Age > 80 && person.ActivityType == ActivityType.Leisure)

            this.totalPremium += 6.5m * CoverDays;

        else if (person.Age > 80 && person.ActivityType == ActivityType.Sport)

            this.totalPremium += 9.5m * CoverDays;

        // more rules to come!

    return this.totalPremium;

Kā redzams no koda, tad polises prēmijas aprēķinam nav izvēlēta pati elegantākā un smukākā konstrukcija, kādā veidā tiek rēķināta prēmija konkrētajai polisei.

Ja bizness izdomās jaunus likumus vai prasības, kādā veidā tiek rēķināta prēmija, tad nepieciešams būs veikt izmaiņas TravelPolicy klasē, kas savukārt var izraisīt kļūdas kādos citos sistēmas apgabalos, tādā veidā padarot sistēmu kopsummā nestabilu.

Lai ievērotu O/C principu, jāpanāk, ka jauna prēmijas aprēķināšanas loģika neprasītu izmaiņas TravelPolicy klasē, bet gan to būtu ērti un eleganti ieviest sistēmā papildinot tikai noteiktu apgabalu, kas atbild par prēmijas aprēķinu.

Viens no variantiem, kā to var realizēt, ir ieviest prēmijas kalkulatora elementu, kurš savukārt tiktu realizēts ar dažādu mazo rēķinātāju implementācijām, kuras tiktu pielietotas katrā no situācijām, kurā konkrētā rēķināšanas loģika var tikt pielietota.

Pirms šāda veida refaktoringa noteikti ir nepieciešams konkrēto vietu apaudzēt ar vienumu testiem, kas pārbaude eksistējošo loģiku un sistēmas uzvedību, tādā veidā iegūstot pārliecību, ka kods un loģika atbilst vismaz tai loģikai, kas bija realizēta iepriekš.

Tātad sekojoši refaktoringa soļi ir nepieciešami:

Iznest prēmijas aprēķinu ārpus polises klases.
Pārveidot rēķināšanas loģiku un mazākām realizācijām, kuras aprēķina prēmiju pasažieriem pēc nepieciešamajiem biznesa nosacījumiem.

Pirmais refaktoring solis – iznesam rēķināšanas loģiku ārpus polises klases:

private readonly IPremiumCalculator calculator;

public TravelPolicy()

    Persons = new List<Person>();

    // use strategy pattern to get instance to calculator

    calculator = new TravelPolicyPremiumCalculator();

Jaunā prēmijas aprēķina metode:

public decimal CalculateTotalPremium()

    totalPremium = calculator.Calculate(this);

    return totalPremium;

Prēmijas aprēķinātājs:

public class TravelPolicyPremiumCalculator : IPremiumCalculator

    #region IPremiumCalculator Members

    public decimal Calculate(TravelPolicy policy)

        decimal premium = 0m;

        foreach (var person in policy.Persons)

            if (person.Age <= 21 && person.ActivityType == ActivityType.Leisure)

                premium += 2.5m * policy.CoverDays;

            else if (..)

         return premium;

    #endregion

Kā redzams no koda, tad pēc refaktoringa ir sadalītas atbildības: nav vairs polises klase, kas nodarbojas arī ar prēmijas aprēķinu, kā arī ir atsevišķi izdalīts prēmijas aprēķinātājs, ar kuru polises sazinās caur klašu interfeisu, tādā veidā paslēpjot implementācijas detaļas prēmijas iegūšanai, kas savukārt dod iespēju nākotnē aizvietot prēmijas aprēķina loģiku ar kādu pavisam citu realizāciju.

Otrais solis, lai uzlabotu ceļojuma polises prēmijas aprēķina loģiku un vēl vairāk ievērotu O/C principu (jaunas biznesa prasības ieviešana neprasītu praktiski nekādu esošā koda pārrakstīšanu vai modificēšanu), ir ieviest prēmijas aprēķina noteikumus, kas tiek piemēroti katram no ceļotājiem pēc konkrētām biznesa prasībām.

Izveidosim noteikumu interfeisu, kas tiks piemērots konkrētā rēķināšanas solī:

public interface ICalculationRule

    bool IsMatch(Person person);

    decimal Calculate(TravelPolicy policy, Person person);

Pēc tam izveidojam visus nepieciešamos rēķināšanas nosacījumus kā kopu.

private readonly List<ICalculationRule> rules;

public TravelPolicyPremiumCalculator()

    this.rules = new List<ICalculationRule>(new ICalculationRule[]

                                                    new JuniorLeisureRule(),

                                                    new JuniorSportRule(),

                                                    new AdultLeisureRule(),

                                                    new AdultSportRule(),

                                                    new OldLeisureRule(),

                                                    new OldSportRule()

});

Piemērs no viena rēķināšanas noteikuma:

public class JuniorLeisureRule : ICalculationRule

    public bool IsMatch(Person person)

        return (person.Age <= 21 && person.ActivityType == ActivityType.Leisure);

    public decimal Calculate(TravelPolicy policy, Person person)

        return 2.5m * policy.CoverDays;

Metode IsMatch() tiks izmantota, lai katrai personai no saraksta tiktu atrasta konkrēta rēķināšanas loģika (vienkāršības pēc šeit netiek risinātas konfliktu situācijas, kad vienai personai tika piemeklētas vairākas rēķināšanas loģikas).

Jaunā uzlabotā prēmijas aprēķināšanas metode prēmijas kalkulatorā:

public decimal Calculate(TravelPolicy policy)

    decimal premium = 0m;

    foreach (var person in policy.Persons)

        var rule = this.rules.FirstOrDefault(r => r.IsMatch(person));

        if (rule == null)

            throw new InvalidOperationException("No rule found.");

        premium += rule.Calculate(policy, person);

    return premium;

Kā redzams, tad pēc refaktoringa kods izskatās pavisam savādāk – īsāks, sistematizētāks un saprotamāks. Ir izdalītas visas nepieciešamās atbildības un katra klase sistēmā ir ar kādu vienu konkrētu mērķi.

Ja bizness nāks klajā ar jaunu rēķināšanas prasību, tad sistēmā atliks:

izveidot šo jauno noteikumu
pievienot to visai noteikumu kopai
pievienot vienumu testus, kas pārbauda konkrētās prasības realizācijas atbilstību prasītajam.

Noteikti nevajadzētu aizrauties ar O/C principu jau pašā sākumā un darīt to up-front. Ja klase/komponente ir jāmaina pirmo reizi, to iespējams, ka labāk izdarīt tajā momentā. Ja klase vai komponente jāmaina jau otro reizi, tad iespējams, ka ir piemērotākais moments pārveidot programmas struktūru tā, lai O/C princips tiktu ievērots.

Jebkurā gadījumā jārēķinās ar to, ka ka O/C principa ievērošana sarežģī koda uzbūvi.

Pirms principa pielietošanas ir patiesībā jāapzinās, vai konkrētā izmaiņa pieprasa principa ievērošanu un jāizvairās no liekas abstrakcijas ieviešanas savās sistēmās.

Cerams, ka noderēs!

Pārējie raksti SOLID sērijā:

Šodien pirmais no S.O.L.I.D. grupas - "S"

valdis.iljuconoks — Sun, 31 Oct 2010 20:12:00 GMT

“S” apzīmē - The Single Responsibility Principle (SRP).

The Single Responsibility Principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.

Tātad šis pagalvojums definē to, ka klasei ir ieteicams nodarboties un risināt tikai kādu konkrētu noteiktu problēmu. Jo vairāk atbildības uzņemas klase, jo lielāka varbūtība, ka pie izmaiņām, tiks ieviestas un izstrādātas jaunas kļūdas.

Zemāk ir dots pavisam triviāls piemērs, lai uzskatamāk nodemonstrētu Single Responsibility principu. Piemērs ir no apdrošināšanas biznesa, bet tas nekas :)

Piemēram, ir sistēmā definēts apdrošināšanas pieteikums (InsuranceApplication). Klase pēc savas būtības risina daudzas problēmas, piemēram:

apdrošināšanas pieteikums ir spējīgs sevi novalidēt jeb pārbaudīt datu pareizīgumu;
māk izdot polisi;
un attiecīgi māk arī pabrīdināt klientu par to, ka polise ir sekmīgi izdota.

Pieņemsim, ka klienta pabrīdināšana nepieciešama tikai internetā (sistēmas komponente – Web Sales) izdotajām polisēm. Klašu diagramma attēlota zemāk.

Tradicionālajā veidā mēs definētu izdošanas metodi (Issue), kurā savukārt būtu iestrādāta loģika, kas pārbauda, no kuras sistēmas tiek izdota polise, un attiecīgi iekļautu klienta pabrīdināšanas (NotifyClient) metodes izsaukumu savā ķēdītē vai arī gluži pretēji - nē. Zemāk dotais piemērs ir tikai ar placeholderiem, lai lieki nepiesārņotu ēteru..

public class InsuranceApplication

    public int SourceSystem { get; set; }

    public void Issue()

        Validate();

        // issue logic here

        if (SourceSystem == 1)  // 1 - web sales

            NotifyClient();

    public void NotifyClient()

    public void Validate()

Viena no pamat kļūdām, kas pieļauta šajā koda uzbūvē, ir, InsuranceApplication klase zina pārāk daudz jeb klasei ir jāatbild par pārāk daudzām lietām – apdrošināšanas pieteikums zina, no kādas sistēmas šī konkrētā polise ir bijusi pieteikta un attiecīgi arī reaģē uz to izdošanas brīdī – informējot klientu par jauno polisi tikai un vienīgi interneta polises gadījumā.

Jaunā klašu diagramma ievērojot SRP principu būtu apmēram šāda:

Tātad:

Izveidojam vienu bāzes (abstraktu vai arī virtuālu) klasi, kas reglamentē kopējo jeb generic izskatu apdrošināšanas polises pieteikuma klasei, kas sastāv no validācijas un izdošanas metodēm.
Būtu jānodefinē divas apdrošināšanas pieteikuma apakšklases, kuras realizētu katrai no sistēmām nepieciešamo funkcionalitāti.
Tikai polises interneta pieteikuma apakšklasē, būtu realizēta klienta pabrīdināšanas funkcionalitāte, jo tā nav nepieciešama BackOffice sistēmā.
TODO: nepieciešams būtu arī atdalīt klienta pabrīdināšanas komponenti no tiešas izmantošanas interneta polises pieteikuma klasē (gaidi burtu “I” no S.O.L.I.D. grupas), bet to mēs izdarīsim vēlāk.

NB! Jāpiemin, ka SRP princips ļoti noder gadījumos, kad mainot kādu no funkcionalitātēm jeb atbildībām, ko uzņemas realizēt klase, nav nepieciešams pārkompilēt arī visas tieši saistošās sistēmas. Piemēram, pirmajā variantā, kad netika ievērots vēl SRP princips, mainot klienta pabrīdināšanas mehānismu (piemēram, no elektroniskā pasta uz SMS) nāktos pārkompilēt arī backoffice sistēmas komponentes, kurām loģiski nav nekāda sakara ar klienta pabrīdināšanas jeb notifikācijas sistēmas komponenti, kas tiek izmantota tikai interneta polisēm.

Ko tad patiešām dod šī principa ievērošana:

Zemākas pakāpes atkarību (angl. coupling) starp sistēmas komponentēm un augstākas pakāpes saistība (angl. cohesion) sistēmas moduļa vai komponentes iekšienē.
Samazinās if un switch nosacījumu skaitu izejas kodā, jo katra no atbildībām tiek veikta un risināta attiecīgi citā vietā.
prasību izmaiņas ietekmē pēc iespējas mazāku apgabalu sistēmā, kā rezultātā samazināsies potenciālo problēmu skaits, kas var tikt saražots labojot kādu no problēmām, ko klase risina.
Vairākas mazas klases ar mazāku jeb specifiskāku atbildību nodrošina elastīgāku sistēmas uzbūvi.

Šis OO dizainēšanas princips ir pavisam vienkāršs un saprotams un nav nekāda raķešu zinātne, tomēr, jāsaka, ka esmu secinājis, ka arī cilvēkiem ar šo dizainu visvairāk problēmas sagādā to atpazīt kodā un pareizajās vietās pielietot.

Cerams, ka noderēs!

Pārējie raksti SOLID sērijā:

EF metadatu failu ielādes issue

valdis.iljuconoks — Fri, 29 Oct 2010 23:13:28 GMT

Vienā no projektiem saskāros ar interesantu problēmu.

Setups projektiem apmēram šāds:

Ir Windows Service aplikācija, kas kalpo kā entry point servisiem.
Ir servisu implementācijas bibliotēka, kurā ir realizēts kāds konkrēta servisa darbība. Servisa implementācija izmanto EF datu modeli, lai darbotos ar datubāzi, pieslēgtos un iegūtu datus, manipulētu ar tiem un saglabātu atpakaļ datubāzē.
Servisa pārvaldnieks ielādē servisu dinamiski (izmantojot reflekciju – System.Reflection), jo tas esot labāk, ērtāk un elastīgāk.

Daļa no servisa pārvaldnieka realizācijas (dynamic keywords ir tikai ātrākai un ērtākai piemēra parādīšanai – patiesībā reālā dzīvē nekad neesmu izmantojis šo iespēju :)):

var asm = Assembly.Load("ClassLibrary");

var typ = asm.GetType("ClassLibrary.Class1");

dynamic instance = Activator.CreateInstance(typ);

var result = instance.GetCount();

Fragments no servisa implementācijas realizācijas:

public int GetCount()

    int result = -1;

    using (var ctx = new DemoEntities())

        result = ctx.Table1.Count();

    return result;

Kad no servisa pārvaldnieka notiek servisa implementācijas ielāde un izpilde, pēkšņi saņemam sekojošu kļūdas paziņojumu:

Kļūdas paziņojums ir pat ļoti OK, jo secinām, ka servisa pārvaldnieka konfigurācijā nepieciešams arī nokonfigurēt EF pieejas un mapping datus, something like this:

<?xml version="1.0" encoding="utf-8"?>

<configuration>

  <connectionStrings>

    <add name="DemoEntities"
         connectionString="metadata=res://*/DataModel.csdl|res://*/DataModel.ssdl|
                           res://*/DataModel.msl;provider=System.Data.SqlClient;
                           provider connection string=&quot;
                           Data Source=localhost;Initial Catalog=EF_DEMO;
                           Integrated Security=True;
                           MultipleActiveResultSets=True&quot;"
         providerName="System.Data.EntityClient" />

  </connectionStrings>

</configuration>

Tomēr, kad pēc šāda veida vingrojuma izdarīšanas savā trace plūsmā redzam paziņojumu:

System.ArgumentException: The specified default EntityContainer name 'DemoEntities' could not be found in the mapping and metadata information.
Parameter name: defaultContainerName
at System.Data.Metadata.Edm.ClrPerspective.SetDefaultContainer(String defaultContainerName)
at System.Data.Objects.ObjectContext.set_DefaultContainerName(String value)
at System.Data.Objects.ObjectContext..ctor(EntityConnection connection, String defaultContainerName)
at ClassLibrary.DemoEntities..ctor(EntityConnection connection) in …

tajā momentā gribas kliegt – WTF??

Pēc apmēram puses no darba dienas, kad pārrakts ir gandrīz viss savs kods, izdarbināti dažādi memory dump un atkļūdošanas rīki (vēl joprojām uzskatu, ka windbg ir labākais Tavs ražošanas vides draugs) nākas atgriezties pie developera “kad nestrādā” rīku sequences pēdējā tooļa – Read F* Manual.

MSDN ieraksts par šo tēmu runā sekojošo:

The full name of an assembly with the embedded resource. The name includes the simple name, version name, supported culture, and public key, as follows:

ResourceLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

Resources can be embedded in any assembly that is accessible by the application.

If you specify a wildcard (*) for assemblyFullName, the Entity Framework runtime will search for resources in the following locations, in this order:

The calling assembly.
The referenced assemblies.
The assemblies in the bin directory of an application.

If the files are not in one of these locations, an exception will be thrown.

Uzmanību piesaistīja tieši wildcard lietošanas piezīmes 2. punkts – referenced assemblies. Cik zināms, tad Windows Service nestartējas tajā direktorijā, kurā .exe fails fiziski atrodas, bet gan %SystemDirectory%. tā kā 1. un 3. punkts diezvai šajā gadījumā nostrādā. Šī hipotēze tika apstiprināta arī ar Windows Forms testa klienta izveidi tieši tam pašam servisa implementācijas apgabalam, simulējot servisa pārvaldnieka darbību no Windows Forms aplikācijas.

Nākamais solis bija izpētīt referencētās bibliotēkas no servisa pārvaldnieka puses. Par cik servisa pārvaldnieks izsauc servisa implementāciju dinamiski, tad references, kas būtu veidotas no Visual Studio, protams, ka nebija. Tomēr servisa implementācijas bibliotēkas pielikšana servisa pārvaldnieka projektam kā referenci šo interesanto problēmu nerisināja.

Kā izrādās, tad pieliekot klāt referenci uz kādu citu bibliotēku Windows aplikācijai un neizmantojot *nevienu* tipu no šīs bibliotēkas, saka priekšā kompilatora optimizācijas departamentam: “Lūdzu, neraksti šo particular bibliotēku pie savu bibliotēku referencēm, jo mums viņa hr** zin kāpēc ir piereģistrēta kā reference, neko taču no viņas mēs neizmantojam!”

Zemāk arī redzams piemērā:

Lai nepieciešamās bibliotēkas parādītos “References” sadaļā un EF noklusētais ielādes mehānisms darbotos korekti, nepieciešams pielietot vismaz vienu kādu tipu no nepieciešamās bibliotēkas. Tā arī izdarījām:

namespace ReferenceDemoWinService

    internal static class Program

        /// <summary>

        ///     The main entry point for the application.

        /// </summary>

        private static void Main()

            var dummyReferenceType = new ClassLibrary.Class1();

            ServiceBase.Run(new ServiceBase[] { new Service1() });

Skatoties uz servisa pārvaldnieka bibliotēku:

References jau izskatās labāk un EF ir vieglāk strādāt – t.i., pēc references uz servisa implementāciju pielikšanas un kāda no tipa izmantošanas savā kodā, veicināja bibliotēkas parādīšanos “References” sadaļā servisa pārvaldnieka projektā un veicināja arī EF ielādēt meta datu failus pareizi un no attiecīgās bibliotēkas.

Cerams, ka noderēs un nebūs Jums jāpavada pāris stundas vienkārši blenžot monitorā un mēģinot izdomāt, kas par lietu.

Happy coding!