C# architecture for large application - c#

Can you please tell me some tutorials/books about thinking a large application in c#.
I have worked with 3 tier, but i need something more specific:
a way to design panels, so that for specific users specific panels will load and specific dlls
a database management so that when a user modifies an entry, others can not modify that entry
should i use entity framework or should i go old school with db and class creation
any links on the above will be greatly appreciated
thanks a lot!

Kind of a broad subject but two books I would recommend giving a read regardless of what language you are doing or the specifics of your project:
Code Complete
Design Patterns
If you have specific questions about how to accomplish something I would post it on here or google it.

Sharp Architecture is just such an architecture. It's pretty detailed and a lot of work has gone into it.

NDepend documentation comes with two white books and also online blog posts and articles concerning the architecture for large .NET application:
Partitioning code base through .NET assemblies and Visual Studio projects (8 pages)
Defining .NET Components with Namespaces (7 pages)
Control Components Dependencies to gain Clean Architecture
Re-factoring, Re-Structuring and the cost of Levelizing
Evolutionary Design and Acyclic componentization
Layering, the Level metric and the Discourse of Method
Fighting Fabricated Complexity

That's not gonna be covered by a single book or tutorial.
You need to decide a UI framework, data access technology, patterns and the overall architecture. And of course you need an in-depth knowledge on .NET framework, & how the CLR works. It's nothing C# specific. Since you have UI customization (Panels) requirements, WPF is definitely a better candidate for UI framework, than WinForms.
That being said, my recommendations -
For C#: Pro C# 2010 and the .NET 4 Platform
.NET & CLR: CLR via C#
UI Framework - WPF: Pro WPF in C# 2010
Use MVVM with WPF. MVVM will keep you on track maintaining the Separation of Concern. You can follow Microsoft's Prism guideline. For large applications with sophisticated UI requirements Prism is a better choice. You might need to use Dependency Injection. MEF is there to go hand-to-hand with MVVM & Prism.
Yes, Entity Framework can handle concurrency issues, but such feature is available in almost any other data access framework. Entity Framework provides lots of other facilities, but when using it you should have clear idea of what you're doing. Otherwise you might end up with performance issues. Programming Entity Framework is definitely gonna help.

With respect to the panels/UI architecture, it might be useful to look at Prism (from Microsoft patterns & practices). It's an architecture/set of libraries to handle composite UI, where the UI is loaded at runtime and composed of independent communicating parts. One note, it is built for use with WPF or Silverlight; there is an older library with similar functionality for WinForms, called "CAB", that is no longer supported.
As far as data access, it sounds like you are looking to implement active record locking while a record is open for editing in the UI; this is an independent feature from the actual data access code you use. It might be easier to implement database-level locking if you are using straight ADO.NET versus EF, which adds layers of abstraction.

Microsoft .NET: Architecting Applications for the Enterprise - with a very good code example and there is a chapter on concurrency
Professional Enterprise .NET
ASP.NET 3.5 Website Programming: Problem - Design - Solution
I guess, there are not any online recources that could compete the complexity of these books.

My go to book with these kinds of questions is Jeffrey Richter's CLR via C# book. It takes you all the way from how your class construction impacts memory on the stack/heap to best practices for these types of discussions. Especially loading assemblies on the fly and the best way to accomplish this.
It will also bring your skills up a notch and Jeff is a great writer.
I recommend this book to EVERY C# developer I know and they always come away better. Is that what we all hope for?
Good luck!

If you want to learn fast and get to the meat of the technology fast, I would recommend getting a Pluralsight account as that would cover the technologies you would need and highlight others you may not have heard about. A monthly subscription would be about the same cost as a decent book.
Pluralsight.com

Related

Implementing C# Business Objects (CSLA)

We are about to commit to implementing Rocky Lhotka's CSLA as an application development Framework for our Visual Studio 2008 solutions. I would like to test the water on SO and am particularly interested in developer's opinions of the approach in comparison with other ORMs such as Entity Framework or nHibernate.
Also, what is the learning curve like and is it as easy (as I have heard) to maintain the applications written to this methodology?
Also would be very interested to hear from any Public Sector (especially Government Agencies) who have implemented this.
Thanks,
MaS
CSLA is not an ORM framework. It is a framework for implementing business objects. However, there are code generators available which can generate data access code for you. The CSLA framework is based on Active Record Pattern. This pattern will not scale for large scale project. In my opinion, you should implement a prototype. The goal of the prototype should be to:
Define a layering Scheme
Unit Testability of Classes
How the framework plays well with other framework
How it fits with other OR mapping tools
Learning Curve
If your evaluation seems to be positive against the above items, then go for it. In short, there should be a proper justification for using such a framework. You should not go with some one's advice, rather try it out by your own.
The learning curve of CSLA isn't too bad but be prepared to spend some time reading in the book. We have taken care of a lot of the learning curve for you by generating a DAL (Parameterized SQL or Stored Procedure support) for you, so it adds an ORM feel to CSLA only because it manages the DAL for you if you choose. But you can completely use it as just a set of BO templates. I find that active generation makes it much easier to upgrade to newer versions of CSLA as well as add functionality without having a strong need for an intermediate class.
Thanks
-Blake Niemyjski (Author of the CodeSmith CSLA Templates)
I love CSLA.
I used it to implement some ASP.NET 2.0 applications, some very large. It's easy to understand (after you understand Root, Child and Switchable objects), but you'll rely heavily on code generation (like CodeSmith).
Main question is: do you need CSLA? What feature do you like, or you just need to use some ORM? Today, I'm writing new applications with ADO.NET Entity Framework and it's more productive than CSLA.
Keep in mind CSLA isn't a metodology, but just a tool: you'll need to understand it and to tweak it when appropriate.
CSLA is a business object framework. There are many strategies for dealing with Data access - there is much overlap between ORM and data-access. I have had a lot of success using Linq-to-SQL in a Data Access Layer to simplify development. I think this is an approach that will work for you - especially given (based on your comments) your need to support both SQL Server and Oracle.
Using a seperate DAL is well documented in Rocky's book and samples on www.lhotka.net
As far as TFS - it's an ALM tool for Source Control, Project Managment and Build Automation. You would want to put the CSLA Source under source control like any other code. The simplest approach would be to include CSLA in your solution.
Another approach would be to compile it seperately and use a file reference in your projects to the CSLA.DLL. In TFS Automated build there is a property group which you could put the path to that DLL on your build server.
Lastly Rocky sells CSLA training videos on his website at http://download.lhotka.net/default.aspx?t=Core38
You can check Rocky's thoughts on SOA in the following broadcast:
http://www.slickthought.net/post/Minneapolis-Developer-Roundtable-Podcast---Talking-REST.aspx
The main thing you will need to grasp is that CSLA is a Business framework. Even though ORMs can give you basic validation (and other) features they do not IMHO really compensate for the lack of a solid business layer. You can of course use an ORM with CSLA (there is an example of using EF in the CSLA examples and NHibernate is used as an example in the CSLA Contrib project I believe) but the technologies are just complimentary.
The learning curve... well that depends on you. I found it quite easy to get started with. i think if you have a good grasp of OO you should be fine to get something basic up and running soon. The recent videos released are also very good to get yuo started.

Developing a new application with .NET?

I have to develop a basic "line of business" application with the usual functionality like orders, stock control, sales, reports, etc.
I will use WPF to develop this application to run on Windows but I want to develop it "open" so I can do a Windows Forms application using the same structure (maybe to run over Mono) or even a Silverlight module. Can someone that did something like that (and survived) give me a sugestion on a guideline or something like that where I can find good practices? I'm a Delphi developer with some intermediate knowledge on C# but there are so many "amazing" libraries, frameworks and patterns that I'm a little lost on what would be good for that project.
Something like: Use EF (maybe wait for ef4?) or nHibernate, or ADO.NET, and expose your data using WCF, or webservices, or forget Mono because of the flexibility loss, etc. Can someone give me a tip on how you would do it? If someone has a bad experience in this type of project, it would be nice to hear from you as well. There is a lot of learning in the wrong decisions too :)
Mono doesn't implement WPF, it's not even on the roadmap. I'm not sure about Entity Framework...
You could probably do it in Silverlight (which has an open source implementation), but it's not ideal for creating desktop (although it is possible since Silverlight 3)
Where do I start?
First, from your description, you're in over your head.
Second, you're trying to pick a technology stack when everything is new to you.
In the best situation, I'd recommend a good training class in a few of the technologies you mentioned so you get a better understanding of them. I'd also recommend a mentor, someone who's done this before.
Reality though, may not allow for training or a mentor. In that case I'd recommend writing several real-life throw away programs. Take one piece of business functionality and try to write it in a few of the technologies you mentioned. If one feels better, and gives you what you want DECISION MADE! Don't stop with the first one that seems to work, try some more.
You should also listen to some good podcasts. I recommend Dot Net Rocks for a good grasp of the technology. The earlier podcasts for this site were also a very good source for some design discussions StackOverflow podcast
Best of luck.
I had to do something very similar recently in WPF. I have an ASP.NET background, but I have never worked with WPF (or WinForms for that matter), and it had me stumped for a while, but the longer I have been working on it (about 3 weeks now), the easier it has gotten. I really just searched Stack Overflow and Google for code snippets similar to what I was doing, and worked through them and changed them as needed. My company bought a book that helped me out as well (It was WPF Unleashed published by Sams), and it was pretty good. I do wish you luck on your first WPF app.
If you separate the business model and business logic from the user interface,
using MVC (Model View Controller) or MVVM (Model View View-Model) or a simular design pattern,
then you can have multiple user interfaces connected to the same business model + business logic and even connect the same user interface to other business models + business logic.
Thank you all for your suport... Brad, I'm already following your advices, doing some test cases to see what looks good... my problem is that altough I can develop an application in WPF and have a intermediate understanding in using the wpf databindings, generics, linq, anonymous objects, all the cool stuff, I always hear about this and that as the solution for all the worlds problems (like mvvm, or parallel programming, or functional languages, etc) and makes me feel "wrong" in my decisions and a bad developer if I do not use any of this nice technologies. I know the concepts but do not dominate it, and seems a lot of things to learn, sadly I do not have that much time.
Thomas, exactly because mono do not support WPF i want to make the application as isolated as i can, so I can do a simple winform layer to manipulate the data.
darthnosaj, thank you, I'm doing that too, searching internet and found much information (and this nice site full of hellpful people :) )
And Danny, thats what i think i need... will take a look on some sample applications using mvvm and see if that works for me. For what i heard is almost a crime not to use in that case in wich I want that kind of isolation.
Again, thanks all :)
I would suggest you keep your application N-Tier. Make all the entities, data adapter, and business logic separated from the actual desktop application. This way you can use WPF on the Windows platform and use Mono/GTK# on the Linux/Mac platforms.
You will only need to write duplicate code to support the actual GUI application functionality, while your code from the separate entity/data access/business logic library (e.g. DLL/class library) can be used in both your WPF and Mono/GTK# projects. Just add the DLL as a reference to the WPF and Mono/GTK# projects.
There is a good video from Channel 9 on building N-Tier applications
There is also MSDN documentation and guidelines on building N-Tier applications

What components of the .Net framework should a professional developer typically avoid?

.Net is a huge framework with some functionality that appears to target beginners or becomes problematic if much customization is involved. So what functionality available in the .Net framework do you feel professional developers should avoid and why?
For example, .Net has a wizard for common user management functions. Is using this functionality considered appropriate for professional use or a beginner only?
One component/feature/class, etc per answer please so votes are specific to a single item.
Typed DataSets
ASP.NET *View Controls
ASP.NET *DataSource Controls
MS Ajax
jquery, and other js frameworks like prototype etc., are a more lightweight and flexible alternative. The MS Ajax controls may seem great initially, until you really need a custom behaviour out of the scope of the controls.
Microsoft themselves have recognised this to some extent in that jquery will be bundled with upcoming versions of visual studio, with intellisense support.
I think generally most controls/features that do a lot of work "behind the scenes" can cause a lot of trouble. No problem using a GridView if that layout is exactly what you want - but it very rarely is, and a Repeater is probably a better choice. UpdatePanels can save you lots of work if you want an ajaxy feel to your site, but compared with a jQuery AJAX call they - sorry to say so - suck. The user wizard you mention can be really useful during development, but if membership functionality is required in the project it should be built as an integrated part of it.
So in summary: Professional programmers should do the job themselves and write code that specifically satisfies their clients needs, and only take in ready made parts of the .Net Framework when that is in fact exactly what they need.
Thread.Abort
Here is an excellent article by Ian Griffiths about Why Thread.Abort is Evil and some better alternatives.
Remoting is generally a good one to avoid, at least if you're targeting 3.0 or above and can therefore easily host messaging endpoints in-process.
Linq To XML
XmlDocument/Xpath is easier to use, if you want strong typing to parse your document use xsd.exe or Xsd2Code.
EDIT
which one do you prefer ?
IEnumerable<XElement> partNos =
from item in purchaseOrder.Descendants("Item")
where (int) item.Element("Quantity") *
(decimal) item.Element("USPrice") > 100
orderby (string)item.Element("PartNumber")
select item;
or, with XmlDocument and XPath
var nodes = myDocument.SelectNodes("//Item[USPrice * Quantity > 100]");
.Net is a huge framework with some functionality that appears to target beginners or becomes problematic if much customization is involved.
It's the "appears to target beginners" that's the real problem.
Typed data sets are a great example. VS provides a nice simple UI to functionality that should be used only by rank beginners building extremely simple demo applications and experienced professionals who understand every nuance of the ADO.NET object model and what typed data sets are actually doing. Nobody in between those two poles should touch it, because there's a good way to learn every nuance of the ADO.NET object model and typed data sets aren't it.
Or take LINQ. It's seductively easy to write LINQ code without having a good understanding of IEnumerable<T>. But it's not so easy to write maintainable LINQ code without that knowledge.
You can think of .NET like an onion with many layers. For example the .NET compact framework is a subset of full .NET. Further there are "extra" layers on top on .NET in the form of "Extensions" which are optional installs for new features which have not yet been made part of .NET proper. An example of this would be when Microsoft released ASP.NET 3.5 Extensions which has now been rolled into .NET 3.51.
Another way to think of .NET is as a set of "libraries" you can use. For example there are a set or routines to support RegEx. If you want or need regular expressions, then you use these functions, if not you can simply ignore them. SImilary functions for things like trigonometry or security.
So I guess it really boils down to what do you need for your application? If you are doing scientific programming you may well want the trig functions. A graphical app will require functions that a console application would not. Web apps probably do not need to use the clipboard functions etc.
I really don't think there are any bad APIs in .NET, just programmers who use them in inappropriate ways.
There is lots to avoid in the WinForms library.
Avoid DataBinding to most standard WinForms controls. There are many bugs in that area which will lead to lots of head scratching. Or at least that has been my experience. NumericUpDown is a good example of this buggy mess.
Also avoid the standard WinForms controls when dealing with large datasets. They do a lot of data copying and can't deal well with large datasets.
Avoid ListView in "Virtual" mode as it is full of bugs.
In general I just recommend staying away from WinForms. If you have the option go for WPF or at least buy a good, well supported (and hopefully less buggy) 3rd party forms library.

Desktop Applications: Architectural Frameworks?

I'm wondering if there are any architectural frameworks out there to create desktop or standalone applications, in Java or C# for instance. It seems that there are tons of them available for web applications but I can't find many good resources on frameworks or architectural best-practices for desktop development.
Ideally I would like to know if there is any source code available of desktop applications that would be considered to have a good architecture or are built with a certain framework.
While not directly related to desktop applications if you are looking for decent source code for well written projects I asked a similar question:
Open source C# projects that have extremely high code quality to learn from.
People gave some pretty good suggestions there:
Scott Hanselman's The Weekly Source Code series (usually
managed C#)
Code written by Microsoft Patterns & Practices team.
SharpDevelop (written in C#)
Mono (most of the framework in C#)
Paint.Net (written in C#)
NHibernate (written in C#)
The Castle Project (written in C#)
xUnit (written in C#)
.Net Framework Source Code
In the lightweight app category, JSR 296 for Java (to be in future Java 7 possibly) is a framework handling the basics like resource management and actions. Lots of links here:
http://tech.puredanger.com/java7#jsr296
Scaling up a bit, you could look at various RCP frameworks like:
Eclipse RCP: http://wiki.eclipse.org/index.php/Rich_Client_Platform
NetBeans Platform: http://www.netbeans.org/products/platform/
Spring RCP: http://spring-rich-c.sourceforge.net/1.0.0/index.html
Comparison article: http://www.infoq.com/news/eclipse-rcp-netbeans-platform
UPDATE: It has been mentioned (by Mark Reinhold at Devoxx '08) that JSR 296 will be included in Java 7.
Further update: JSR 296 is dead. JavaFX is the current direction for client-side Java.
There's a new .NET architectural guidance package from Microsoft patterns & practices for WPF that is code named "Prism" -- it's basically a "next generation" Composite UI Application Block (without the SCSF tooling). It uses Dependency injection, Composite pattern throughout, etc.
There is a pretty good DNRTV screencast demoing it.
Check Microsoft's Smart Client Software Factory. It contains code samples and documentation.
Overview
This software factory provides proven
solutions to common challenges found
while building and operating composite
smart client applications. It helps
architects and developers build
modular systems that can be built and
deployed by independent teams.
Applications built with the software
factory use proven practices for
operations, such as centralized
exception logging.
The software factory contains a
collection of reusable components and
libraries, Visual Studio 2008 solution
templates, wizards and extensions,
How-to topics, automated tests,
extensive architecture documentation,
patterns, and a reference
implementation. The software factory
uses Windows Forms, Windows
Presentation Foundation, Windows
Communication Foundation, and the
Enterprise Library 3.1 – May 2007
release. With this release, the
Composite UI Application Block is
included in the software factory.
In Java, Naked Objects -- http://nakedobjects.org/home/index.shtml
JMatter -- implementation of naked objects -- http://jmatter.org/. pretty good.
both of them are open source.
On the Java side, there are several projects aimed at Rich Client Platforms (RCP is the new buzzword for 'desktop' apps):
Eclipse RCP (if you are OK using SWT
instead of Swing)
Spring RCP (which
is in the process of being
overhauled into Spring Desktop)
NetBeans RCP (which I'm not
particularly impressed with, but
that is getting some traction)
JSR 296 (Application Framework) - I
actually really like this one
Google any of the above and you'll get tons of info.
You can use some of the same approaches in client development that you use in web development, such as Model View Presenter. The System.Windows.Forms namespace has everything you need to build a client application in C#, with the rest of the .NET Framework available to provide the services you need (such as IO and remoting).
As far as source code for solid architectures in desktop apps, look at the code for Paint.NET and SharpDevelop. Both have very different approaches that will be interesting to you.
Sorry for the .NET slant of this reply. It's what I know best. :)
I would recommend CSLA .NET framework by Rockford Lhotka: http://www.lhotka.net/cslanet/Default.aspx
It comes will full source code as well as sample client applications built in ASP.NET, WinForms and WPF.
I just found the Composite Application Guidance for WPF and Silverlight which looks very interesting. It was published in February 2009.
We develop in .NET technologies here.
Our friends here working on client applications develop their software to the Model View Presenter design pattern that is often associated with Web Development. For them they find it works very well, I believe it may be worth checking out.
The Smart Client Factory (mentioned by Panos) may also be useful to you, though it's not a framework but more of a library of best practice solutions to common problems.
Specifically to organized presentation framework of ui functions we have been using infonode docking windows, that's a windowing framework using an eclipse like appearance (drag views anywhere, close them, undock them etc., skinnable of course). there's a gpl version for open source products out, altough afaik the developer licence is not that expensive ($299 each).
Check IdeaBlade's Cabana For DotNet C#.
http://www.ideablade.com/CAB.html
Cabana Sample App
The Cabana application is a simple smart client reference app with a crisp, feature-rich user experience that is easy to deploy and operate over the web. Cabana demonstrates:
An easy approach to the Composite UI Application Block from Microsoft ’s Patterns & Practices Group.
Maintainable, reusable code through UI composition.
Separation of Model (business logic and data access) from Presentation.
The Model-View-Presenter pattern.
Performance tuning.
And more.
I recently published DesktopBootstrap. It's my attempt to factor out many of the common elements of creating medium to large scale desktop apps.
You can find it here.

How would you architect a desktop application in C# 3.0

I've created a simple desktop application in C# 3.0 to learn some C#, wpf and .Net 3.5.
My application essentially reads data from a csv file and stores it in a SQL server CE database. I use sqlmetal to generate the ORM code for the database.
My first iteration of this app is ugly as hell and I'm in the process of refactoring it.
Which brings me to my question. How would you architect a desktop database app in C#?
What are the best practices?
Do you create a Database Abstraction Layer (DAL) which uses the sqlmetal generated code? Or is the generated code enough of an abstraction?
If you use DAL pattern, do you make it a singleton or a static member?
Do you use the View-Model-ModelView pattern with the DAL pattern?
Apologies if this seems like a long open ended question, but I have been giving this a lot of thought recently.
I see a lot of examples on how to architect an enterprise n-tier app in C# but not that many on architecting standalone desktop apps.
I would start with the Composite Application Guidance for WPF (cough PRISM cough) from Microsoft's P&P team. With the download comes a great reference application that is the starting point for most of my WPF development today.
The DotNetRocks crew just interviewed Glenn Block and Brian Noyes about this if you're interested in hearing more from them.
Even better, Prism is not nearly as heavy as the CAB was, if you're familiar at all with that from the WinForms days.
The answer is "it depends" as always.
A few things to think about:
You may want to make this fat client app a web app (for example) at some point. If so, you should be sure to keep separation between the business layer (and below) and the presentation. The simplest way to do this is to be sure all calls to the business logic go through an interface of some kind. A more complex way is to implement a full MVC setup.
Another thing you may consider is making the data access layer independent of the business logic and user interface. By this I mean that all calls from business logic into the DAL should be generic "get me this data" rather than "get me this data from SQL" or even worse "run this SQL statement". In this way, you can replace your DAL with one that accesses a different database, XML files, or even something icky like flat files.
In short, separation of concerns. This allows you to grow in the future by adding a different UI, segmenting all three areas into their own tier, or changing the relevant technology.
Before architecting anything you should define requirements for your app.
It's a common error of beginner developers - starting writing code ahead of thinking about how it would perform. My advice will be to try to describe some feature of you application. It will help you to feel how it should be implemented.
As for useful learning resources I would highly recommend you to take a look at CompositeWPF it's a project designed specifically to teach developers best practices of desktop app development.
I'd start with Jeremy Miller's Build Your Own Cab series.
I was an early CAB adopter. I learned a lot from digging into that technology and reading all the .NET blogs about application architecture.
But recently I had a chance to start a new project, and instead of using CAB I went with StructureMap & NHibernate and borrowed some of the patterns that Jeremy uses (in particular, his way of handling event aggregation). The result was a really simplified, hand-tooled framework that does everything I need and I love working with it.
As to the specifics of your question: I use a Repository for data access. I initially wrote some ADO.NET code and used data readers and mapped my objects. But that got old real fast, so I grabbed NHibernate and was really pleased. The repositories use NHibernate for data access, and my data access needs are pretty simple in this particular app.
I have a service layer (exposed via WCF, Duplex channels) that utilizes the repositories. My app is basically client-server with real time updating (and I know your question was just about clients, but I would use the same technologies and patterns). O
n the client side I utilize MVP with StructureMap for IoC and some very simple event aggregation strategies for cross-class communications. I code to interfaces for just about everything. The only other thing I did was borrow from the CAB the idea of a flexible "Workspace" for dynamically displaying views. I wrote my own Workspace interface though and implemented my own DeckWorkspace and TableWorkspace for use in my app (these were really simple things to write).
A lot of my decisions in this most recent application were the result of experience and pain I felt using other frameworks and tools. I made different decisions this time around. Maybe the only way to really understand how to architect an application is to feel the pain of doing it wrong beforehand.
I would say yes, it could easily be structured towards smaller applications. There is a learning curve towards getting started, but honestly, it helped me understand WPF better than attempting to start from scratch. After starting a project with CompositeWPF and then starting another project without it, I found myself attempting to duplicate features of CompositeWPF on my own because I missed those features! :)

Categories