|
|
Browse by Tags
All Tags » Architecture (RSS)
-
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 one is best: http://www.lhotka.net/weblog/MiddletierHostingEnterpriseServicesIISDCOMWebServicesAndRemoting.aspx The key thing is that a layer is a logical separation of concerns , and a tier directly implies a process or network boundary. Layers are a design constraint, tiers are a deployment artifact. How you layer your code is up to you. Many people, including myself, often use assemblies to separate layers. But that is really just a crutch – a reminder to have discipline. Any clear separation is sufficient. But you are absolutely correct, in that a great many developers have trouble maintaining that discipline without the clear separation provided by having different code in different projects (assemblies). 1) CSLA doesn’t group all layers into a single assembly. Your business objects belong in one layer – often one assembly – and so all your business logic (validation, calculation, data manipulation, authorization, etc) are in that assembly. Also, because CSLA encourages the use of 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 library) -> Person.cs (linked from BusinessLibrary.Client) -> Person.Server.cs One key thing is that both projects build a file called BusinessLibrary.dll . Also, because Person.cs is a shared file, it obviously has the same namespace. This is all very important, because the serializer requires that the fully qualified type name ("namespace.type,assembly") be the same on client and server. In my case it is "BusinessLibrary.Person,BusinessLibrary". The Person.Server.cs file contains the server-only parts of the Person class - it is just the rest of the partial class. The only catch here is that it can not define any fields because that would obviously confuse the serializer since those fields wouldn't exist on the client. Well, actually it could define fields as long as they were marked as NonSerialized. Of course you could also have a partial Person.Client.cs in the Silverlight class library - though I haven't found a need for that just yet. One thing I'm debating is whether the 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 is already there. Looking forward beyond 3.5, it is possible I'll need to add support for ASP.NET MVC because that technology eschews data binding in favor of other techniques to create the view - but it is too early to know for sure what I'll do in that regard. Since CSLA .NET has always abstracted the business object concept from the data access technique you choose, it automatically supported LINQ to SQL (and will automatically support ADO.NET EF too). No changes required to do that were required, though I did add Csla.Data.ContextManager to simplify the use of L2S data context objects (as a companion to the new Csla.Data.ConnectionManager for raw ADO.NET connections). And I enhanced Csla.Data.DataMapper to have some more powerful mapping options that may be useful in some L2S or EF scenarios. LINQ to Objects did require some work. Technically this too was optional, but I felt it was critical, and so there is now "LINQ to CSLA" functionality provided in 3.5 (thanks to my colleague 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 the cost of moving data over the wire, and the cost of serializing/deserializing the data on each end of the wire. These are very real, measurable costs. In both cases the middle tier means an extra machine to license, administer, maintain, power and cool. It is an extra point of failure, extra potential for network/CPU/memory/IO contention, etc. These costs come with every server you add into the mix. Anyone who’s ever been a manager or higher in an IT organization has a very good understanding of these costs, because they impact the budget at the end of every year. However, the security benefits of a middle tier are real. In a 2-tier web model the database credentials are on the web server. Even if they are encrypted they are there on that machine. A would-be hacker could get them by cracking into that one machine. Switching to a 3-tier model moves the database credentials onto the middle tier and off the web server. Now the web server has credentials to the app server, but not the Read More...
|
-
Since I have been getting into a habit lately of posting videos etc.. over the last few weeks, I thought I would post some links to google Videos I found today, they are from the Google Scalability Conference that was held a while back. So here are the videos I found to date: Building a Scalable Resource Management VeriSign's Global DNS Infrastucture YouTube Scalability Lessons In Building Scalable Systems ms Scaling Google for Every User MapReduce Used on Large Data Sets Lustre File System SCTPs Reliability and Fault Tolerance Scalable Test Selection Using Source Code and of course, I can't forget the links that Peter has collected over here . hth, /P For more information, go to http://www.paulfallon.com . Read More...
|
-
Interesting read, “Escape Metropolis: Bridging the Divide Between Developers and Architects” /Paul For more information, go to http://www.paulfallon.com . Read More...
|
-
Both the July drop of the Web Service Factory or Service BAT is out and the June SCBAT are out. I am super excited about this as it is nearing V1 and we are using both of these in production code. I have been blogging about the Service Bat since the begining . I talked about my SCBAT experiences here and that the SCBAT has helped us reduce our UI and CAB costs 5 to 1. Remember to install the the new June 2006 release of the Guidance Automation Extensions and Toolkit , first! A couple of real cool things on the Services BAT according to Tom : The installation process has been streamlined And the biggest news is that the Service Factory now has a brand new guidance package dedicated to helping you build data access layers using ADO.NET 2.0. The goal of this guidance was not to be an object-relational mapping framework or an entirely new approach to data access. Instead it's designed to take out some of the repetitive and error-prone work of creating a data access layer by hand, by helping to create some (but not all) of the key classes used in a data access layer. Most of you are probably already aware that the choice of available technologies for building data access layers will be changing significantly in the future with the advent of LINQ to ADO.NET . We're already working with these teams to start planning for these technologies, and we'll be publishing samples that show how the Service Factory guidance will look in a LINQ to ADO.NET world. I said this in all three of my recent INETA talks: PAG is the best group in Microsoft right now. Technorati Tags: Smart Client , CAB , Architecture , Software Architecture , ADO.NET , LINQ , SOA , WCF Share this post: Email it! | bookmark it! | digg it! | reddit! | kick it! Read More...
|
-
Microsoft is holding an architect contest at Tech Ed this year. Click here for details. For more information go to www.lhotka.net . Read More...
|
|
|
|