This has come up in a couple threads over the past 2-3 weeks, so I thought I'd elevate it to a top-level discussion topic.
CSLA .NET 1.x was composed of around 5 assemblies. I recieved a lot of negative feedback about this, because people had to reference numerous assemblies to use the framework.
CSLA .NET 2.0-3.7 was composed of 1 assembly. I recieved some kudos for this when I did it, and in the past month I've received a bunch of negative feedback about this.
It is possible that a small number of vocal new CSLA users are voicing these objections and that the majority likes one assembly. Or it is possible that the majority has been silently living with one assembly, while really wishing for many assemblies. I don't know, and that's the purpose of this thread.
CSLA .NET 3.8.1 now has two assemblies: Csla.dll and Csla.Web.Mvc.dll. This could be a temporary anomoly, since MVC is included in .NET 4.0. Or it could be the model on which CSLA .NET 4.0 is based.
Right now CSLA .NET 4.0 consists of three projects:
It could consist of a whole family of projects. For an extreme example:
Most projects would need to reference 2-4 assemblies on the client, and probably 3-5 on the server.
A more realistic example:
In this case a typical client would need 3 references, and a typical server would need 2-3 references. A web server (Web Forms or MVC) would need 2-4.
Some of this I'd planned on doing regardless - specifically pulling the "legacy" data portal channels out into their own project(s), and leaving only the WCF channel in the core framework.
I hadn't planned to break all the different interface technologies (WPF, WCF, Web Forms, etc) into their own assemblies.
So I think the real question for this thread is whether I should break the interface technologies into separate projects/assemblies - thus pretty much requiring that you always reference 2+ assemblies to build a project using CSLA .NET, instead of the 1 assembly you reference today.
I cast a strong vote for a single assembly!
Joe
I would like to keep a single assembly.
I think the logic that 3rd party products come in more than one assembly is a bit misleading; the ones I use which do come with (dozens) of assemblies also have other tools that add the appropriate references, but thats not the case with Csla. I'm not convinced the tools to manage references have improved that much either, as I still hit problems with two referencing wanting a different version each of a 3rd reference..
I was using Csla.Net in the 1.x days, and remember that it was an incredible PITA having multiples.
For those that want the split, what advantages do you see?
ajj3085:
For those that want the split, what advantages do you see?
I think, for those of us who see multiple assemblies as a benefit (of which I am one) is that it allows Rocky to more easily continue to support the multiple UI technologies that Microsoft keeps spewing out. There are already ongoing struggles with WinForms vs. XAML, and I believe Rocky has stated that CSLA 4.0 will likely switch to an ObservableCollection-based collection class rather than a BindingList-based class. That pretty much kicks WinForms binding right where it hurts. However, since he doesn't want to abandon the entirety of all Winforms apps using CSLA, there is likely going to have to be a separate inheritance tree for the base classes. That seems like a perfect situation for split assemblies.
While you certainly can maintain all of that within one assembly, doing so tends to clutter the environment, as you have access to namespaces you're never going to need, depending on your situation. While it certainly doesn't hurt anything to have it all lumped together, having multiple assemblies allows for a cleaner separation of the different technologies, as well as locations (in my warped mind, I see a set of server-only assemblies as well.) It would also force people to consider more carefully what they're pushing down to their clients.
Also, like it or not, it's my opinion that MS is driving us towards this whether we want it or not. The "client profile" feature streamlines the .NET assemblies that get pushed to the client. The five different UI technologies are separated into different assemblies. Microsoft's application blocks have long required multiple assembly references to work correctly. I know the headaches of multiple assembly references, but I think in the long run it will make life easier for Rocky to maintain - or potentially pass off maintenance of some pieces to someone else.
HTH
- Scott
Csla (FieldManager, Core, base classes, dataportal, wcf host/client portal, all resources, commonrules, objectfactory)
- Csla.Data (Data access helper classes for ADO.NET, EF, L2S)
- Csla.Linq (Linq base classes/indexing/C5)
- Csla.DataPortal (legacy DataPortal hosts and dataportal client)
- Csla.Windows (legacy BindingList base classes, sortedbindinglist/filteredbindinglist)
- Csla.WF
- Csla.Silverlight (Silverlight dataportal wcf host)
A "typical" Csla BusinessObject project would need Csla + Csla.DataAccess + possibly Csla.Linq.
- Csla.Web.Asp (ASP.NET)
- Csla.Web.Mvc (ASP.NET MVC)
- Csla.Client.Wpf
- Csla.Client.Silverlight (UI Helpers + client dataportal/wcf)
- Csla.Client.Windows (Windows controls/extenders )
A typical UI project would need same BO references above + the actual client technology assembly.
And I would prefer to keep all resources in one assembly and have just one set of translated resources.
ILMerge is an interesting idea – but what really brought
this to a head was that I recently took dependencies on two Microsoft
assemblies that aren’t installed automatically with .NET 3.5 SP1. That
threw enough people for a big enough loop that I addressed both issues in
different ways.
The Interactivity assembly is now in my Dependencies folder –
which is a pretty lame solution since users lose localization and XML help
unless they change the reference to point to the real install location
(assuming they install the Blend SDK).
The Mvc assembly is now referenced only by the Csla.Web.Mvc
project. Which is arguably a better solution, but radically reduces the
discoverability of the CslaModelBinder class, which is very important for
ASP.NET MVC development.
Taking a dependency on ILMerge would be even worse I suspect,
because it isn’t even a Microsoft tool. I shudder to think about the emails
I’d get for forcing developers in locked down dev environments to
argue with their managers to let them install this (relatively random) tool.
Interestingly enough, a large percentage of CSLA users are not
open source nuts, and can’t or won’t install numerous open source
tools just to get CSLA to build. Heck, a fair number won’t install supported
Microsoft SDKs to get CSLA to build.
Taking a dependency on ILMerge would be even worse I suspect, because it isn’t even a Microsoft tool.ILMerge is actually come from MS, I think is from MS Research group. This is just a tool to merge multiple assembly into one which can be used when you're packaging a version build or can be added as a step to your build script. This would not need a reference to a project which would take dependency and force developer to download another install.
![Smile [:)]](/emoticons/emotion-1.gif)
, because we all can have our cake and eat it too)![Wink [;)]](/emoticons/emotion-5.gif)
There are some things to keep in mind in this discussion.
Perhaps most importantly, the mobile object concept requires that the base classes and their supporting infrastructure be in a consistent assembly across platforms - server, client and Silverlight. In short, anything that is [Serializable] fits this requirement.
Since that (to me) core set of types will already have to be replicated into 3 projects (minimum), there's a mulitplier effect. If I break anything out of 'core' into a separate part of 'core' then I have 6 instead of 3. Then 9, etc.
So there's no sense considering breaking out anything directly tied to the base classes. This includes validation, authorization, business rule processing, field manager, the various collection base classes, data binding support and at least part of LINQ to CSLA. These are all directly connected to the base class type structures and therefore must be in 'core' - because I only want one 'core' per platform.
The things that are relatively easy to break out are the interface support types for WPF, Silverlight, Windows Forms, Web Forms, MVC, WCF, asmx, Workflow, etc.
Other things could be teased apart, like the data portal, but with some serious effort, and at a cost - mostly in terms of either optimization or by making a lot more things public than I'd like.
Still other things could be separated, like Csla.Reflection, but I'm not sure to what end. This is because none of the other assemblies could work without it, so you'd always have to reference it no matter what, so then why make it a seperate assembly? All that would do is add complexity for me and anyone using CSLA - which makes no sense to me at all.
I can see arguments for breaking out the various interface technologies. And there are strong advantages to this, as should be clear from the Interactivity and Mvc dependencies I've recently encountered. Imposing the Interactivity (Blend SDK) requirement on WPF/Silverlight developers seems reasonable to me - why wouldn't you want those features?? But imposing that requirement on everyone else doesn't make sense.
I don't see the value in arguing that breaking it apart reduces complexity. I use namespaces to organize the types, and I find it hard to imagine web developers are confused by the types in Csla.Windows - what sane web developer would look there in the first place???
Conversely, there's a clear increase in complexity here, in that developers will need a deeper understanding (in this new world) about what types are in which assemblies - and which assemblies must be referenced on the client vs the server, etc. For some people this is a non-issue, and that's fine, but I am 100% confident that some confusion and FAQ entries would come out of this :)
Breaking out the different interfaces makes a lot of sense to
me. In our organization adding a requirement like a dependency for MVC / Blend
could cause us not to be able to take advantage of newer releases of the
framework. Our development, build and testing environments are not easily modified.
One of the core ideas behind CSLA is that it’s focus is on
the business logic layer and not the UI. As you have indicated the UI
components could easily be separated into their own assemblies.
I don’t see any benefit of splitting the ‘core’
platform up
Thanks
From: RockfordLhotka
[mailto:cslanet@lhotka.net]
Sent: Wednesday, November 11, 2009 3:18 PM
To: chris.dufour@wigets.net
Subject: Re: [CSLA .NET] RE: Many CSLA assemblies?
There are some things to keep in mind in this discussion.
Perhaps most importantly, the mobile object concept requires that the base
classes and their supporting infrastructure be in a consistent assembly across
platforms - server, client and Silverlight. In short, anything that is
[Serializable] fits this requirement.
Since that (to me) core set of types will already have to be replicated into
3 projects (minimum), there's a mulitplier effect. If I break anything out of
'core' into a separate part of 'core' then I have 6 instead of 3. Then 9, etc.
So there's no sense considering breaking out anything directly tied to the
base classes. This includes validation, authorization, business rule
processing, field manager, the various collection base classes, data binding
support and at least part of LINQ to CSLA. These are all directly connected to
the base class type structures and therefore must be in 'core' - because I only
want one 'core' per platform.
The things that are relatively easy to break out are the interface support
types for WPF, Silverlight, Windows Forms, Web Forms, MVC, WCF, asmx, Workflow,
etc.
Other things could be teased apart, like the data portal, but with some
serious effort, and at a cost - mostly in terms of either optimization or by
making a lot more things public than I'd like.
Still other things could be separated, like Csla.Reflection, but I'm not
sure to what end. This is because none of the other assemblies could work
without it, so you'd always have to reference it no matter what, so then why
make it a seperate assembly? All that would do is add complexity for me and
anyone using CSLA - which makes no sense to me at all.
I can see arguments for breaking out the various interface technologies. And
there are strong advantages to this, as should be clear from the Interactivity
and Mvc dependencies I've recently encountered. Imposing the Interactivity
(Blend SDK) requirement on WPF/Silverlight developers seems reasonable to me -
why wouldn't you want those features?? But imposing that requirement
on everyone else doesn't make sense.
I don't see the value in arguing that breaking it apart reduces complexity.
I use namespaces to organize the types, and I find it hard to imagine web
developers are confused by the types in Csla.Windows - what sane web developer
would look there in the first place???
Conversely, there's a clear increase in complexity here, in that developers
will need a deeper understanding (in this new world) about what types are in
which assemblies - and which assemblies must be referenced on the client vs the
server, etc. For some people this is a non-issue, and that's fine, but I am
100% confident that some confusion and FAQ entries would come out of this :)
I like Justin’s suggestion that results in four assemblies. Another option would be to align the number of assemblies to Visual Studio’s targets. In this case it would be divided into Server and Client only.
The server/client/Silverlight split is a given. There's no way around having at least three different Csla.dll builds for the different platform targets.
Personaly i would like a small subset of assembly's, the ASP.NET MVC assembly is a perfect example to deploy seperately.
Not using LINQ to CSLA would also mean that the C5 stuff can be put into a assembly.
It's almost the same as u explained, so i vote for:
I put the start of the 4.0 change log online
http://www.lhotka.net/Article.aspx?id=3852b8d8-e2f7-4277-b77e-bf375125b6c9
This includes a brief description of the new folder/project structure, specifically designed to make sure no one is happy ;)
\Bin\...
\Samples\CslaNet\...
\Samples\CslaLight\...
\Source\Csla.client\...
\Source\Csla.core\...
\Source\Csla.Silverlight\...
\Source\Csla.Silverlight.test\...
\Source\Csla.test\...
\Source\Csla.Web\...
\Source\Csla.Web.Mvc\...
\Source\Csla.Windows\...
\Source\Csla.Xaml\...
\Source\Dependencies\...
You can also see the structure in svn if you'd like
http://www.lhotka.net/cslacvs/viewvc.cgi/core/trunk/Source/
The changes actually go deeper than it might first appear, as I'm taking this opportunity to clean and organize a number of things. Generally speaking this should only affect you if you have CSLA in your build process - in which case it will probably be a big deal.
On the other hand, I do plan to release binaries with 4.0, so if you don't build (or want to build) CSLA you won't have to.
The output assemblies now are:
I do think I'll stick with this model, as it moves UX-specific dependencies like the Interactivity and Mvc assemblies out of the core so they only affect people using a specific UX technology.
For example, if you are using Web Forms you only need core, and it has no external dependencies. But if you are doing WPF you'll need the Interactivity assembly. Or if you are using ASP.NET MVC you'll obviously have the required Mvc assembly from Microsoft.
I'm experimenting currently with this configuration:
Core:
UX:
So far the only snag I've run into is that the WPF CslaDataProvider uses an internal property, otherwise the UX code already used only public members or interfaces. And that's how it should work, so this caught (in my mind) a bug with the WPF CslaDataProvider control.
I'm going to work with this for a while and see if I like it - maybe even do an alpha release to see what you all think when working with real bits.
The drawbacks are clear - more assemblies is more complexity and I fully appreciate those arguments (and tend to side with them).
But the one single benefit that (to me) favors this change is that it would enable sub-teams to work on specific UX support with minimal risk to the core. Specifically I'm thinking Windows Forms and Web Forms as being areas where I will spend little to no time, but where there are people who are heavily invested in those technologies that may want to contribute their time to improve support in those areas.
OK, there's also the external reference benefit - where csla.web.mvc can reference ASP.NET MVC, and where the Silverlight and Xaml projects can directly reference the Blend 3 SDK (because to me that's a required install for doing WPF/Silverlight anyway).
I realize I'm probably in a small minority here, but I don't think I'd even be able to attempt to try the multiple assemblies. I don't just toss a binary Csla into my source control, I actually have the source built just like other projects from source. This has allowed me to a keep a few small changes to core csla which I need or find useful, and I can easily spot all the code changes from version to version. So right off the bat, I'm faced with more ccnet integration projects to manage, and multiple places to update code (I actually have a WinForms app with embedded Wpf controls, and web forms apps), or, more likely, I'll spend time recombining to a single assembly because overall that will be easier to manage. With my own project, I'd like to combine multipe assemblies into one, but I think that ship has sailed.
RockfordLhotka:
But the one single benefit that (to me) favors this change is that it would enable sub-teams to work on specific UX support with minimal risk to the core. Specifically I'm thinking Windows Forms and Web Forms as being areas where I will spend little to no time, but where there are people who are heavily invested in those technologies that may want to contribute their time to improve support in those areas.
This is actually one of my main concerns, and maybe more clarity will help. Improvements to old UI technology is one thing, but if something in Csla core breaks something in Csla WinForms (an interface change, for example), is the expectation that the community will maintain those changes, or will the UI assemblies at least be updated to continue working as they currently are with Csla?
OK, there's also the external reference benefit - where csla.web.mvc can reference ASP.NET MVC, and where the Silverlight and Xaml projects can directly reference the Blend 3 SDK (because to me that's a required install for doing WPF/Silverlight anyway).
I can see why this would be a small benefit, so this is just a question because I'm curious, but I know there may not be a reason anyone knows; with the Blend reference, why is there an assembly which seems required to do development, but isn't included with the framework itself? Unless this is one of those things were like MVC it will be in the next VS anyway, it just seems really odd to me to require developers to redistribute an assembly which will always be required.
It is no longer clear to me that ASP.NET MVC 2 will be in the
.NET 4 release. I think it will be, but I’m not 100% sure, since MVC seems to
be working like EF – where they do out-of-band releases.
I have no idea why the Interactivity dll isn’t in the framework.
The behavior and trigger action concepts in that assembly are really important
for XAML work on SL or WPF. Sure, you can live without them, but then you need
some complex code or third-party code to do the same thing. Very strange…
I realize I'm probably in a small minority here, but I don't think I'd even be able to attempt to try the multiple assemblies. I don't just toss a binary Csla into my source control, I actually have the source built just like other projects from source. This has allowed me to a keep a few small changes to core csla which I need or find useful, and I can easily spot all the code changes from version to version.
This (to me, at least) introduces a slightly-different question for Rocky.
I know that CSLA is essentially an open-source framework. But have you ever considered just deploying the CSLA binaries? For those folks who use the framework "as is", not having to download the code and re-compile for every version could save a step.
I'm not saying that the source code should no longer be available - I'm just wondering if there will be an additional download of just the binary DLL's.
- Scott
I know that CSLA is essentially an open-source framework. But have you ever considered just deploying the CSLA binaries? For those folks who use the framework "as is", not having to download the code and re-compile for every version could save a step.
Yes, with the 4.0 version I do plan to provide binaries as well as source.
Copyright (c) Marimer LLC