|
|
Browse by Tags
All Tags » Architecture (RSS)
-
PDC is approaching rapidly and Microsoft is opening up its communication around the next wave of technologies; one thing I believe to be particularly interesting is Codename Dublin . This technology supplements Windows with much needed application platform components to enhance the WCF and WF design experience. Among other things it includes infrastructure services for message correlation and forwarding, content-based routing and transaction compensation. I guess you can look at WCF and WF as a frameworks and Dublin is infrastructure services around those frameworks. Read More...
|
-
In preparation for the next public release of CSLA Light (CSLA .NET for Silverlight), I'm going to do a series of posts describing the basic process of creating a CSLA Light application. This first post will provide a high-level overview of the project structure and some concepts. First, it is important to realize that CSLA Light will support three primary physical architectures: a 3-tier (or SOA) model, a 3-tier mobile objects model and a 4-tier mobile objects model. At all times CSLA Light follows the same n-layer logical architecture of CSLA .NET, where the application has the following layers: Presentation/UI Business Data Access Data Storage The primary goal of CSLA Light and CSLA .NET is to support the creation of the Business layer in such a way that the interface points to the Presentation/UI layer and to the Data Access layer are clearly defined. To a small degree, CSLA Light will assist in the creation of the Presentation/UI layer by providing some custom Silverlight controls that solve common issues and reduce UI code. Like CSLA .NET, CSLA Light is not an ORM and does not really care how you talk to your database. It simply defines a set of CRUD operators - locations where you should invoke your Data Access layer to retrieve and update data. 3-Tier or SOA Model If you use CSLA Light in a 3-tier (or SOA) model, your physical tiers are: Silverlight Service Database You can treat these as tiers, or as separate applications where you use SOA concepts for communication between Read More...
|
-
I've been engaged in a discussion around CSLA .NET on an MSDN architecture forum - you can see the thread here . I put quite a bit of time/effort into one of my replies, and I wanted to repost it here for broader distribution: I don’t think it is really fair to relate CSLA .NET to CSLA Classic. I totally rewrote the framework for .NET (at least 4 times actually – trying different approaches/concepts), and the only way in which CSLA .NET relates to CSLA Classic is through some of the high level architectural goals around the use of mobile objects and the minimization of UI code. The use of LSet in VB5/6, btw, was the closest approximation to the concept of a union struct from C or Pascal or a common block from FORTRAN possible in VB. LSet actually did a memcopy operation, and so wasn’t as good as a union struct, but was radically faster than any other serialization option available in VB at the time. So while it was far from ideal, it was the best option available back then. Obviously .NET provides superior options for serialization through the BinaryFormatter and NetDataContractSerializer, and CSLA .NET makes use of them. To be fair though, a union struct would still be radically faster Before I go any further, it is very important to understand the distinction between ‘layers’ and ‘tiers’. Clarity of wording is important when having this kind of discussion. I discuss the difference in Chapter 1 of my Expert 2005 Business Objects book, and in several blog posts – perhaps this Read More...
|
-
I spent some time over the past few days using my prototype Silverlight serializer to build a prototype Silverlight data portal. It is still fairly far from complete, but at least I've proved out the basic concept and uncovered some interesting side-effects of living in Silverlight. The good news is that the basic concept of the data portal works. Defining objects that physically move between the Silverlight client and a .NET web server is practical, and works in a manner similar to the pure .NET data portal. The bad news is that it can't work exactly like the pure .NET data portal, and the technique does require some manual effort when creating the business assemblies (yes, plural). The approach I'm taking involves having two business assemblies (VS projects) that share many of the same code files. Suppose you want to have a Person object move between the client and server. You need Person in a Silverlight class library and in a .NET class library . This means two projects are required, even if they have the same code file. Visual Studio makes this reasonable, because you can create the file in one project (say the Silverlight class library) and then Add Existing Item and use the Link feature to get that same file included into a .NET class library project. I also make the class be a partial class, so I can add extra code to the .NET class library implementation. The result is: BusinessLibrary.Client (Silverlight class library) -> Person.cs BusinessLibrary.Server (.NET class Read More...
|
-
Someone on the CSLA .NET discussion forum recently asked what new .NET 3.5 features I used in CSLA .NET 3.5. The poster noted that there are a lot of new features in .NET 3.5, which is true. They also included some .NET 3.0 features as "new", though really those features have now been around for 15 months or so and were addressed in CSLA .NET 3.0. CSLA .NET 3.0 already added support for WCF, WPF and WF, so those technologies had very little impact on CSLA .NET 3.5. My philosophy is to use new technologies only if they provide value to me and my work. In the case of CSLA .NET this is extended slightly, such that I try to make sure CSLA .NET also supports new technologies that might be of value to people who use CSLA .NET. While .NET 3.5 has a number of new technologies at various levels (UI, data, languages), many of them required no changes to CSLA to support. I like to think this is because I'm always trying to look into the future as I work on CSLA, anticipating at least some of what is coming so I can make the transition smoother. For example, this is why CSLA .NET 2.0 introduced a provider model for the data portal - because I knew WCF was coming in a couple years and I wanted to be ready. Since CSLA .NET already supported data binding to WPF, Windows Forms and Web Forms, there was no real work to do at the UI level for .NET 3.5. I actually removed Csla.Wpf.Validator because WPF now directly supplies that behavior, but I really didn't add anything for UI support because it Read More...
|
-
I recently received this email: Thank you very much for your insightful articles concerning 2 vs. 3 tier models. It’s very refreshing to hear a view point that I’m aligned with. Here at work I’m dealing with network Nazi’s who believe there is no cost of a middle tier and that there is only huge security rewards to reap. I use your articles to support my point but I’m still not getting tremendously far. I have yet to have anyone explain to me exactly how that middle tier is going to really add a significant enough amount of security that will warrant the high price to pay for employing a performance blasting middle-man. There are two scenarios, though they are similar. In the web, adding a middle tier has a very high cost, because the web server is already an app server. It already does database connection pooling across all users on that server. Adding an app server just adds overhead. The only exception here is where the web server is serving up a lot of static content and only some dynamic content. In that case, moving the data access to another machine may be beneficial because it can allow the web server to focus more on delivering the static content. It is important to realize that the dynamic content will still be delivered more slowly due to overhead, but the overall web site may work better. In Windows, adding a middle tier has a cost because the data needs to make two network hops to get to the user. Each network hop has a tangible cost. It would be foolish to ignore Read More...
|
-
I’ve just noticed a nice little article about the importance of Mono (.Net on other platforms). Mono is one of my favorite open source projects, not to mention the significance I feel it has in the .Net domain. Have a look . > Read More...
|
-
It’s time for TechEd Europe again! I’m doing a session on BizTalk Server 2004 and Indigo where I will go through some of the scenarios where these technologies can work together to offer some very interesting solutions. There will be several demos showing off the latest bits of the prototype adapter as well as a little low-level section on how the adapter was developed at the end. If you find this topic interesting then drop by Room 3A on Thursday 7th at 18.15! Read More...
|
|
|
|