 |
|
|
|
|
|
 |
  |
|
April 28th, 2009
I remember that when the first version of Java was released one of the frequent questions was: why doesn’t it have multiple inheritance? This also happened later with C#. The answer in both cases was: you can use interfaces instead. It is not the same, you don’t inherit the logic, but you can at least simulate it by implementing multiple interfaces.
Well, this was obviously forgotten by the people designing C# classes: even worse, they seem not to have been aware of it because most of the classes in v1.0 onward don’t have equivalent interfaces that would allow this.
There’s a real-life example (or should I say everyday example? Because I’ve encountered it a million times, you probably did too) that perfectly illustrates the point: why isn’t there an IControl interface that represents a (windows, web, whichever) control type? The logical answer (and it was probably the real reason the framework designers came up with) would be: well, it would be too difficult to implement. Anything that is supposed to work as a control should really have to be derived from Control. True: but the purpose of interfaces is not only to implement them.
Let’s say I want to create my control type that implements some interface, IMyInterface. How do I reference this component, using a variable of Control type or IMyInterface? Whichever I use it isn’t complete, I have to cast it into the other one and I lose compile-time type safety. I could create a ControlWithMyInterface base class that implements the interface and use this instead of both, but then I’d have to inherit everything from it, which in most cases would not be possible. No, the only solution would be to support the “interfaces instead of multiple inheritance” principle and derive IMyInterface from IControl, but IControl doesn’t exist. Although it wouldn’t be too difficult to implement, one could just put all of Control’s public members into the interface.
There could really be a programming rule enforcing the existence of an equivalent interface for every class, even something that generates them on the fly from its public members. I wonder if there is a pre-processor that can help with this?
By bdrajer | Posted in Microsoft .Net | No Comments »
April 13th, 2009
NHibernate supports fields that are generated by the database, but in a limited way. You can mark a field as generated on insert, on update, or both. In this case, NHibernate doesn’t write the field’s value to the database, but creates a select statement that retrieves its value after update or insert.
Ok, but what if you have a trigger that updates this field in some cases and sometimes doesn’t? For example, you may have a document number that is generated for some types of documents, and set by the user for other types. You cannot do this with NHibernate in a regular way – but there is a workaround…
It is possible to map multiple properties to the same database column. So, if you make a non-generated property that is writable, and a generated read-only property, this works. You have to be careful, though, because the non-generated property’s value won’t be refreshed after database writes.
A more secure solution would be to make one of the properties non-public and implement the other one to support both functionalities. Like this:
//
// This field is used only to send a value to the database trigger:
// the value set here will be written to the database table and can be consumed by
// the trigger. But it will not be refreshed if the value was changed by the trigger.
//
private int? setDocumentNumber;
private int? _documentnumber;
//
// The public property that works as expected, generated but not read-only//
public int? DocumentNumber
{
get { return _documentnumber; }
set
{
// NHibernate is indifferent to this property's value (it will not
// be written to the database), so we have to update the setDocumentNumber
// field which is regularly mapped
_documentnumber = value;
setDocumentNumber = value;
}
}
Here’s the NHibernate mapping for these two:
<property name="DocumentNumber" generated="always" insert="false" update="false"/>
<property name="setDocumentNumber" column="DocumentNumber" access="field"/>
By bdrajer | Posted in NHibernate | No Comments »
March 31st, 2009
The model-view-controller (MVC) pattern has an interesting, let’s call it sub-pattern, that could be more broadly used. The basic purpose of MVC is to “clean up” the data (model) and interface (view) by delegating all the in-between “dirty” logic to the controller. The controller is aware of both the data and the interface and knows how to handle both: it controls what is happening in them, but from the outside. The controller, if written correctly, can be reused for multiple types of model or view. If we go a step further, we could program multiple controllers that know how to handle different aspects of the functionality: in this way we very much get add-ons that we can attach onto non-intelligent components and make them smarter. By choosing which controllers we attach, we can customize the behaviour of our application. And because the controller is made to work “from the outside” it is isolated from the internal implementation of the components: this could make it instantly reusable.
But it could be interesting to generalize the “add-on” controller pattern and make it work in other situations as well. One interesting area of application could be controlling data: if you use an Object-relational manager (ORM) to read your data (and if you don’t, you should), you already have your data in the perfect form for this – that is, as objects. Likewise if you use a traditional data-access layer and then create business entities as object-oriented structures. Usually, these classes contain much of the business logic inside and this is quite natural to do because business logic represents the behaviour of the data. But it’s not good for reusability: whether you combine the data access and business entities or implement them separately, the business logic is tightly coupled with data/hardcoded inside data so it’s not easy to customize. It would be nice if we could externalize at least some parts of it, but keep it as close to data as possible. Even better would be if we could split the logic and implement different aspects as different components.
If we attached controller objects to our data, they could take the responsibility of providing its behaviour. We could have different controller types for different types of behaviour (status changes, automatic calculations etc.), and if we instantiate them using some kind of configuration engine (or dependency injection framework), they will be easy to replace and thus make your application highly customizable.
Of course, these “data controllers” sound similar to what rules engines do, only more lightweight. But how much of an overhead would they add? As always, it depends on what we do, but I would say not too much. They would contain the code we already have, with probably one layer of isolation because it would be split into distinct classes. Would the instantiated rules waste memory? Probably some: but when you consider that the ORM instantiates each record as an object and has a complex infrastructure for tracking its changes; that for each data binding there is a couple of objects created in the interface; that there can possibly be a control (which is quite a large object) bound to each field… It seems that it shouldn’t make a big difference.
The most sensitive bit is collections: there we can have hundreds of records with one control (a data grid) bound to them. In this case, the overhead of the rules engine could be significant compared to the overhead of the interface – but not in comparison to ORM overhead. Again, this depends on how we implement the rules: the rule could be optimized to utilize a single instance for the whole collection – this can be done using an IBindingList implementation where the collection transmits events for everything happening inside it… Of course, here it is the collection which incurs the overhead, but let’s say we would use it anyway for data binding purposes.
Obviously, there’s a lot of technical issues here. This is partly because the base framework doesn’t have built-in support for what we need. But, it is to be expected that having an ORM (which can be interrogated for data structures and from which we can receive notifications when data is loaded/saved) generally helps.
Of course, I’m still talking hypothetically here: but I’ve already made a couple of small steps in the direction of having a living prototype (in fact, I’m testing an minimal working something as we – uhm, speak). More on that in another post.
By bdrajer | Posted in Uncategorized | No Comments »
February 26th, 2009
I tried to find this on the net, and was unable to find a satisfying and simple solution. How do you retrieve hierarchical records (say, from a self-referencing table) sorted by their depth in the hierarchy? Microsoft SQL Server 2005/2008 has a new SQL construct, Here’s one example: a Category table with an ID (primary key) and ParentID (pointing to the hierarchical parent).
WITH CategoryCTE(ID, ParentID, Depth)
AS
(
SELECT ID, ParentID, 0
FROM Category
WHERE ParentID IS NULL – root records
UNION ALL
SELECT cRecursive.ID, cRecursive.ParentID, cCte.Depth+1
FROM Category AS cRecursive JOIN CategoryCTE AS cCte
ON cRecursive.ParentID = cCte.ID
)
SELECT *
FROM CategoryCTE
ORDER BY Depth
By bdrajer | Posted in Databases | No Comments »
January 30th, 2009
This was a brain-twister: not a lot of work but hard to figure out. How does one use CAB in a windows service?
Is this a reasonable requirement, a Composite UI framework in an application with no UI? Well, it is, since CAB is not only about UI… If you have a framework of components that use CAB services and need to run them in unattended mode, it would be much easier to implement CAB support in the service instead of modifying everything to run with as well as without CAB.
I’m going to present one solution that worked for me, but I believe there are other variations. Since your requirements may vary, I’ll describe the general idea so you can modify or improve it.
So, how does CAB fit within a service? There’s a couple of fundamental differences between the two: a service class needs to be derived from the framework-defined ServiceBase class while a CAB application has its own base class, WindowsFormsApplication. A service doesn’t need to have a message loop like a windows forms application does.
But the thing is, CAB doesn’t require any of the windows app features. And this is the crucial detail: CAB is simply a bunch of objects and services attached to your component. When running a CAB application, the CAB infrastructure creates all the necessary services and structures and then starts the application like it’s not different from any other windows app. It is the programmer’s task to have his components keep references to CAB components (like WorkItem) and communicate with them. But the CAB structures are inactive and not required for proper running of a CAB application. If all of the components within it reset their properties that reference the CAB infrastructure, the whole bunch of CAB objects would probably be disposed by the CLR’s garbage collector.
In a windows application, it’s the message pump that holds the application together: when the pump stops, the application exits. In a service, its equivalent is the service object (one or more of them). You cannot substitute a message pump for a service because Windows service host expects to get a running service and nothing else. If a service object is not registered within a specified timeout period of starting the service, Windows will assume the process has hanged -even if there’s a message pump running within it.
So, obviously, one part of the solution is to put our service where the “ordinary” CAB application’s message loop was. This is the CAB application’s Start() method. When you create a windows CAB application, you need to override WindowsFormsApplication’s Start() method and start the message pump within it. Now, for the purposes of creating a service, you can create an equivalent WindowsServiceApplication class and run the service within its overridden Start() method. Since a service doesn’t have a shell, you derive WindowsServiceApplication directly from CabApplication class.
But how do we run the WindowsServiceApplication? We can do this from the Main() method: remember that running the CAB application is equivalent to running an ordinary application: after the CAB startup code creates the necessary infrastructure objects, the application proceeds to run just like any other. What we probably should do, however, is create the service instance using CAB so that everything within it can use CAB. This isn’t necessary: in a similar way to an “ordinary” CAB application, you register with CAB only the components that are CAB-aware.
Here’s the sample code (note that I haven’t tested it, this is a simplified version of the class we have in our application):
using Microsoft.Practices.CompositeUI;
namespace EightBit.CrmService
{
class WindowsServiceApplicationDemo : CabApplication<WorkItem>
{
static void Main(string[] args)
{
WindowsServiceApplicationDemo prg = new WindowsServiceApplicationDemo();
prg.Run();
}
protected override void Start()
{
// uncomment to debug service startup
//System.Diagnostics.Debugger.Break();
// this part ensures that the newly created crm service
// gets attached to the CAB environment
CrmService svc = this.RootWorkItem.Items.AddNew<CrmService>();
System.ServiceProcess.ServiceBase.Run(svc);
}
}
}
I haven’t shown the CrmService class source because it’s not different from an ordinary service – except that it now has CAB dependency properties.
By bdrajer | Posted in Composite UI Application Block, Microsoft .Net | No Comments »
December 30th, 2008
It seems that the Microsoft Sync Framework is being developed in a hurry. It is a quite a big task – or at least it should become big if we’re to have a serious data distribution framework – therefore it probably merits some patience, but the first thing that is sacrificed in similar cases is documentation. So what we now have is a piece of software for which it is not easy to figure out how it works, and once you do, there are cases when you’re left to your own power of deduction to figure out how it’s supposed to work.
I haven’t dug into the framework deeply enough, but I’m digging. And I have the intention to document the findings, even if it means just sketching everything in short sentences. There are many things not obvious until you start disassembling (and Reflector-ing, of course) the innards of the dlls. And even in that case, you have to keep notes because it’s not a simple system. I intend to come back to this subject in the posts to come (and get way more technical), be sure to check back if you’re interested.
I cannot say for sure, but given the complexity of problem the Sync Framework set out to solve, it is commendably (somewhat bravely, even) comprehensive, well thought out – and quite stable for a Microsoft V1. There’s a V2 "on the air" right now, but it’s a technology preview and it mostly contains a more mature version of the stuff we’ve already seen before. But even V2 or V3 would only be the small first step: what it currently does, copying database rows back and forth between PCs is not a mechanism that will allow us to one day easily build distributed systems. Even Sync Framework guys themselves acknowledge that the biggest obstacle is replication conflicts – irregularities that occur when the same piece of data is changed in multiple locations at the same time. Microsoft cannot help but give us a simplified solution in the form of record-by-record detection and resolution, and this is because the framework is in its very early stages: I don’t know even if (or when) it will grow smart enough to handle more serious conflict resolution.
The thing is, record-by-record resolution cannot help you enforce business rules: for example, if your business logic depends on an invoice not containing the same product multiple times, how do you prevent this from happening in a distributed system? Two users working with two different databases can each add a record for a single item, but when the records replicate you get two of them. This really needs to be detected, and not in such way that would require programming a separate copy of validation logic for synchronization issues (which, when you think of it, should validate data that was already succesfully written to the database… I shudder to think of it). The synchronization framework would really need to somehow integrate with validation logic: in this aspect (and this is probably the biggest issue but only one of the issues present), Microsoft Sync Framework is much closer to the start line than to the finish. But at least it’s moving…
The IT industry has so far moved on mostly in a step by step fashion, by implementing better solutions than the existing ones. This is where the Sync Framework will be of most use, to finally help us start thinking in terms of distributed data. Also, once there’s a working system for data distribution, most will be interested in having it. And once they do, it will be much easier to persuade them that they need to structure their data and/or applications differently. Hopefully we’ll be moving onto an application design philosophy in which it is a "good thing" to have distributed data just like it currently is a "good thing" to have object-orientedness, layered structure etc. There’s a good chance CRUD will be the one of the things that we’ll start getting rid of. Because, once you look at it, storing the current state of data (which is the essence of CRUD – Create, Read, Update, Delete – philosophy) is the major factor in causing replication conflicts. If the databases stored operations – that is, changes to the data – besides data itself, it would be much easier to resolve conflicts, many of them automatically. The logic would know what the two mentioned users did – added the same product to the invoice – and act with this knowledge. In this concrete example there would be a much clearer situation for conflict resolution, the system could replay the operations so that the second one gets a chance to detect there already is a record present and act accordingly – be it to add the second quantity to the first or raise an error. Note that now a common validation logic for the operation could be employed… This is light years away from getting "fait accompli" duplicated rows and having to do a Sherlock Holmes to discover what has happened. Of course, this is also light years from where we currently are, but when you think of it, the database servers are way overdue for serious feature upgrades – and in any case, they already store something that resembles this in transactional logs.
So, it seems we’re making the first step in the right general direction, even if we’re not sure what precise direction we should move in. Trying to wrap our heads around distributed data philosphy is good – and seeing this practice widely deployed will be even better.
By bdrajer | Posted in Microsoft .Net | No Comments »
December 26th, 2008
Welcome to the 8bit blog.
This is the first in what we hope to be a series of posts on various subjects related to IT, e-business and application development. We will concentrate on a broad range of topics, some of them highly technical, but for the most part we will try to provide information that is otherwise hard to find, at least in a readable and concise form.
By admin | Posted in Uncategorized | Comments Off
Entries (RSS)
and Comments (RSS).
| | |
