At our company we are developing an application that has a large number of winforms that are all created in the same UI layer, namespace and assembly. Is there a decent way / design pattern to structure this layer?
Our UI layer communicates with the business layer wich consists of mutiple namespace like business.calculation and business.logistics. Can this structure also be used in the UI layer?
It just doesn't feel right to create 100+ winforms in the same winform project.
Cheers!
Yes. A good structure will help keep your sanity as the applcation grows. You'll have some challenges:
Identifying good namespaces
Finding depdencies between them, which results in a logical build order
Maintaining the namespaces as developers add new forms
For example, you might consider grouping the forms into namespaces like:
business.library.ui -- common, reusable UI components might go here
business.calculation.ui -- UI related to the calculation, which depends on the library UI
business.logistics.ui -- UI related to the logistics business area, which depends on the library and calculation UI
I find it easier to structure my namespaces according to the subsystems that make up the whole application, then organise the namespaces for the UI according to use cases.
Related
My Application has the following structure:
myproject (primary Silverlight project)
myproject.Web (website for the app)
myproject.Controls (Class library so I could do some inheritance with controls)
myproject.Classes (Classes representing the data the controls bind to)
It seemed like a good idea having these split into projects with their own sub-namespaces, but I'm running into a lot of coupling issues and that is leading to circular dependency namespace problems.
From what little iOS development I have done, it feels kind of like I am trying to roll my own MVC solution here. What is the recommended way of going about having controls (essentially forms) backed by data in a Silverlight app?
The projects look fine provided the namespaces and assembly names match. You can do the following:
myproject.Classes Can reference none
myproject.Controls Can reference myproject.Classes
myproject Can reference myproject.Controls AND myproject.Classes
myproject.Web Can reference myproject.Classes, but shouldn't need to
I suggest doing that split within the primary Silverlight application itself (a single project with multiple folders). Unless you know right now that you will have to reuse the code within the classes and controls namespaces within different Silverlight applications, I would avoid it. Silverlight is UI, anything you will want to reuse should be in the ASP.NET part of the project (logic, db access, business rules, etc).
If you take this approach, your UI won't become an albatross around your neck.
Keep your Silverlight applications thin, fast and pretty - I promise you won't regret it.
EDIT: The downvote made me realize I was unclear (clearer, more concise version below):
Don't split your solutions into projects based on namespaces - it leads to needless complication. Use namespaces within projects to organize code. Keep project counts to a minimum, and only split when there is a compelling need.
Good Luck!
I'm confused about the architectures which we can use to develop a business application with WPF 4.0 and EF 4.0 technologies.
My first choice was a traditional N-tier architecture contains: UI, Business Logic Layer & Data Access Layer with a disconnected behavior.
In this way I create 3 project for each layer and another project for my Entities/DTOs (Each layer is an assembly). Each layer references only to it's upper and lower layers (That is: UI can see the BLL but can't see the DAL). But all layers have access to the Entity/DTOs assembly for communication purposes.
The problem starts when I want to create a simple CRUD form with a DataGrid for example. The BLL disposes the DataContext of the DAL when returns an Entity/DTO, this is the reason that forced me to use STEs. But yet there are several problems. For example I should call "StartTracking" method for each entity returned from BLL to the UI. In short, I don't sure about this pattern reliability or I think I have to forget about automatic handled CRUD forms.
I use the repository model in my DAL layer but when I search about the repository pattern I find it different. It seems that it's not bad to reference to both of the DAL/Repository and the BLL/Services(Not WCF nor WebServices) layers from the UI and thus we can have a connected environment (Without using STEs).
I see an example in which we can get a person from repository but do something on it using BLL or services:
UI CODE:
var person = new PersonRepository().GetPerson(10);
Bll.Salary.PaySalary(person);
-or-
var person = new PersonRepository().GetPerson(10);
Bll.Person.MarkAsAbsent(person);
Or something like that...
With this pattern we can send the Entities/DTOs to the UI in a connected way while the DataContext is alive.
I don't know if I understand the way of using the repository pattern in big projects. I think it's not clear to naming the BLL or services classes and methods in this way. More over the developers might be confused about where to use the repository methods or BLL/service methods or about where to create the methods (in repositories or BLL/service).
I prefer the N-Tier architecture using a good approach to track the Entities/DTOs changes automatically like STEs.
Would you please recommend the best pattern in such situations or/and reference me to some good books or documents about that.
I put together a sample app that may help with some of your questions. You can review the presentation notes and the sample via my blog post here:
http://blog.alner.net/archive/0001/01/01/wpf_ef_4_sig_presentation_2010.aspx
The sample shows using STEs and includes some helpers to make the Entity Framework STEs work better in a desktop client app.
Repositories are there to hide the details of how you get the data. The idea is that you could swap the implementation of a repository from one that uses a local database, to one that uses a remote web service without the upper layers knowing about it.
Maybe the article Architecture for WPF applications is any help for you.
You might have a look at the BookLibrary sample application of the WPF Application Framework (WAF) as well. It shows a WPF MVVM application together with the Entity Framework applying the described architecture.
Is there a way, given a database or some other source specification for an application, for an entire WPF or Silverlight / XAML application to be generated that emits best practices?
For example, assuming I have a well-normalized database (or some other kind of base specification for an app), is there a tool that can create a well-formed MVVM application. This would include...
XAML (Views) for all of the tables (list and edit) with no code-behind
ViewModels that emits properties extracted from the db schema along with commands or behaviors for all of your standard CRUD operations
Models built with the repository pattern (or some other db abstraction) with interfaces that emit the table design and relationships and a default implementation of your choice (sql, sql ce...whatever).
An ideal tool like this would only do a "first pass" of the application after which the developer would make all necessary changes and modifications.
I don't think there is any such tool but it seems like a tool like this should be possible.
Another related question, in the absence of such a tool (or even if there is one), what tool(s) are best used to get me from a database design (or some other kind of base specification for an app) to working app.
What STEP-BY-STEP process do you take to get from design to basic working application in a couple of hours?
I am just trying to figure all of these practices and patterns and I am getting a pretty good grasp of the pieces but not sure what workflow to use to make it all work together quickly but still allows unit testing of separate concerns.
Thanks in advance.
Seth
Not sure if this is what you are looking for, but you can use LightSwitch
From a process perspective, I build and test my ViewModels first. That allows a division of labor between designing and wiring up the UI and pulling data into the ViewModel.
I'm beginning modelling an existing application for controlling a cash collection terminal. I'm very new to the Prism / Composite Application Library and would like some advice on how I could begin modelling this application using the Prism library.
Basically the application manages a cash terminal that accepts frequent cash drops, counts notes in the deposits, communicates via a 3G/Edge connection with our central server to replicate deposit and other data, and performs cashups. Central to all this is management of the cash canister. The application is not UI intensive, but we are moving away from WinForms to WPF, and I am supposed to use this framework for all future development.
At its most fundamental core, Prism is an application composition framework. It allows you to modularize your application. The thing to start thinking about it what parts of your application need to be modular.
A module is a unit of functionality that is useful on its own, but doesn't make the application useless if it is replaced or removed. For example, in an application I've written for work we have two different types of contacts for which we handle cases. We have a module for each contact type that contributes functionality specific to that contact type. The application is still usable without one or the other and in this way we can work on or test each component individually as well as together.
Hopefully this gives you a guide to how to model your application. Prism seems complicated, but it helps to understand that what you really get with Prism is this ability to slice up your application. From a high level, this is what you'd probably be more interested in modeling.
I am attempting to document a WPF Prism application made up of multiple modules. This scenario begs for module documentation, but I'm not sure if there is a formalized way of doing this in UML, either as separate packages or something more generalized.
Usually, your documentation / design modeling methodology are determined by your company's Software Development Plan or Process. If your company doesn't have one, you may be well served to first define your design documentation process, independent of what fits best for Prism - particularly if you have applications that have been developed that are not reliant on Prism. In my experience, Prism, in and of itself, doesn't lend itself necessarily better or worse to any design modeling approach.
That aside, and with respect to UML specifically, Prism modules can usually be logically divided into packages or use cases quite easily. You've actually already done that when you divided your application into modules in the first place: each module is a loosely coupled, reasonably independent portion of your application.
For example, UI concern modules can often be grouped both according to use case and as separate packages. Take the StockTraderRI for example: the News, Position, and Watch modules lend themselves quite easily to separate use cases (View News, View Position, Add Stock to Watch, etc.) Obviously, these can also be represented easily as separate packages, complete with static class diagrams.
With business or data layer modules, such as Infrastructure or service oriented modules, the representation may be almost exclusively as package / class diagrams, with some use case realization diagrams (sequence, etc.) being used to illustrate communication coming from the UI to the services. Again, with the StockTraderRI application, the Market module and Infrastructure DLL seem to lend themselves to a more static approach.
Again, your approach to documentation and modeling of your application shouldn't be dictated by Prism, as any good modeling language will be able to accommodate Prism.