I don't have a specific question here but I'm more looking for some guidance regarding a new software project I'm starting at work.
Here is a description of the project:
I am refactoring windows software that was written in Visual Basic 6 and uses MS SQL Server for a database. The code is tightly coupled with SQL queries and references old active X controls.
The software can run in a standalone mode where its only running one instance on one computer or in a distributed mode where it runs on several machines simultaneously all connected to a shared data source.
The users of the software need use of a wide range of USB devices that are integrated with the software on the client side. (I'm assuming this means the new version of the software needs to be a desktop application and can not be a browser based web application.)
The new version of the software is going to be updated to use new technologies in an effort to modernize the code and improve performance.
I would like the architecture of the new software be both logical 3-tiers and to use design patterns if appropriate. Although I am new to design patterns it seem like there is an opportunity to use the abstract factory, observer, and singleton patterns together in the new version of the software.
In a very generic explanation the software has an "employee" database table that stores information about employees. The client side has a grid view that allows the user to view the employee information stored in the database and to make modifications to the data through the grid view. Data can be added to the employee database by the client using forms that have text fields and drop down menus. Employee related data can also be captured by USB devices on the client side and then that data can be added to the employee database as well.
In terms of how this relates to architecture I'm guessing there could be an observable singleton employee object that is observed by data display objects like a grid view object and that these data display objects are created by an abstract factory method. (Does that make sense?)
The new software will be written in Visual Basic using Visual Studio 2010. Aside from that none of the other technologies have been decided upon.
I think we will use windows forms opposed to the windows presentation foundation although I'm not sure as there might be some image handling functionality that we want that is better done with WPF.
From what I've read I like the Entity Framework and Linq but I'm not sure how that works in conjunction with the business logic layer with the design patterns I mentioned above.
Also, I'm trying to understand if we could use the windows communication foundation and web services. This makes sense when the software is running in distributed mode but not much sense in the standalone single machine deployment. Adding web services and using IIS might be overkill for what we are trying to accomplish. I don't know.
So this is what I'm working on and what I've been reading about and researching. I would greatly appreciate your thoughts on this and any guidance you can provide.
Thanks!
Aside from the fact that you will learn a lot during the development process I can give you the following recommendations:
Use Stored Procedures in the database for database access. This will prevent concurrency problems and also allows for transactions. This means if something goes wrong (users computer crashes etc) then no data nor data integrity is lost
Treat the windows forms as simply 'interfaces' between the user and the database. Hence they shouldn't contain anything that keeps track of data (let the database do that) and they're only a means of gathering and showing data
I had a very similar experience.
I tried importing a VB6 database project that ran as a standalone app into VB 2005, and the code was very ugly.
One book that I found very helpful with doing three-tier DB applications using VB.NET (VB 2005, actually) was ADO.NET 2.0 with VB 2005 published by Murach. Got me up to speed very quickly, and it gave direct examples of writing three-tier DB applications (business layer, presentation layer, and DB access layer).
Can't remember for sure if there's a newer version of the book, but I was impressed with the layout of that one. It also deals with web apps.
Beyond that, I did some code generation to streamline hacking out the Object classes and the DB access classes for my project.
I believe this project is really going to have you learn and gain a lot of experience.
Like eddy556 said, use the forms only as interfaces. It works better that way.
Plus, if you have any problems, don't hesitate to ask. That's what we the StackOveflow team are here for anyway.
Good Luck.
Related
For my small company I am trying to build a data input form for several departments that input data into SQL tables. I would like to give the user the ability to input data, update existing data, and see graphs of historical data that they have inputted.
I personally know VB.net but my IT head wants to use PowerApp. No one knows PowerApp in the company but he thinks it will be easier to use and implement/share across the company.
Is PowerApp easy to learn?
Can Power App input data into MS SQL?
In general, which is better for my intended use?
Thank you!
YMMV, but in general PowerApps is easier than a programming-language based platform for building apps. It won't be as powerful as the latter, but for the specific example that you mentioned (data input, presentation), it should be fine. Take a look at the documentation, especially in the section about creating an app automatically from your data (the link talks about apps from SharePoint, but the same works for SQL Server as well)
Yes, data integration is built in the platform, and SQL Server (both SQL Azure and on-premises installations of SQL Server) is supported
As always, it depends (which is why this question may be closed for being primarily opinion-based). A full-fledged programming language will always have more power than a "no-code/low-code" solution such as PowerApps, but if what you need to do is within the domain of that solution, it will likely be easier to implement. PowerApps also makes it easier to deploy the app in mobile devices (iOS / Android), which is not as easy to do with VB.NET, but again, that depends on your scenario.
I'm wondering if anyone is currently utilizing Microsoft's Master Data Services? How you are utilizing it? Whether you find it useful? When you believe it would be useful? Thanks!
I have been working with MDS since it was first released as part of a feature pack for SQL Server 2008 R2. While MDS has some compelling features - most notably detailed data lineage, I am not confident in recommending it to clients yet.
My reason for this hesitation is the nature of the install and the tendendency to fail on upgrade or system change. I struggled mightily with the both the SQL Server 2012 RC0 MDS and the RTM installs. There are simply too many brittle aspects of the install (such as the hard requirement that the service be installed on a domain-joined machine and the need to install the Silverlight 5.0 SDK for the client to work properly). I also experienced flakiness in the the Excel add-in.
I see where Microsoft is going and I think the product will eventually be useful. Considering it's purpose (master data repository), MDS must be more 'rock solid' before I would use it in production.
We aren't using it currently in our office, however the presentation Microsoft did in town a while back seemed very interesting. I saw it as sort of a competitor to Oracle's OBAW warehouse. You've probably already looked at these, but Microsoft has a decent set of webcasts that cover how to install and use MDS out here:
http://www.msdev.com/Directory/SeriesDescription.aspx?CourseId=155
I'm anxious to see if anyone else is using it as well, we tend to have a hard time talking our management into letting us try these types of services without being able to point to other corporations that have successfully implemented said product.
We're just starting to investigate the use of MDS to support our consulting practice, specifically around data analytics and ETLs to deduplicate, standardize, and sanitize client data. It's probably just scratching the surface of MDS, but we were led to MDS initially for its inclusion of regular expression capabilities in SQL to transform free-form text data.
Before MDS/DQS, part of the sustainability / enduring-success of a custom database application was heavily dependent on one or both of the following items...
Having a full-time technical resource to manually update the master data. Someone who can work with the Business Experts and make the necessary adjustments to the data in the database.
Developing (in addition to the database/application/etc) a custom UI that is intuitive enough for the less-technical Business Experts to use for managing the master data themselves.
Neither of these were ideal from a cost-perspective. With MDS/DQS, a developer/contractor can come in, design an end-to-end Data Warehouse/BI solution including full integration with DQS/MDS (probably via SSIS packages) with relative ease. The Business-Experts can be trained to manage the master data using a UI they are already very familiar with (ex. Excel), and the developer/contractor can move on to the next project/client.
Also, if the business already has other data sources (via acquisitions or silo'd-yet-overlapping efforts or whatever), MDS can be used to manage all the master data in one centralized location.
It might not be the best MDS product available yet however it does come with SQL Server. Compared to most of the bespoke efforts for accommodating meta-data or master data in warehouse loads it's a pretty good option since most of the time is spent concentrating on the warehouse and the mastering of ancillary or other data isn't normally well accommodated for leaving questionable results. I prefer to use it than create some other flaky option that the customers will find it difficult to maintain. If you have budget however I would consider looking around for something more polished.
Like anything though give master data the respect it deserves. If it is going to be used then it's worth spending the time to model the entities, flow of data and usage correctly. The data stewards will need to savvy and will require training (it's not the most usable interface in the world - to say the least).
As we are a small consulting and development company we don't use MDS internally but we do implement it at customers with a focus on managing the Golden Record as the customers have a myriad of databases and applications all using the same data (customer, product …)
I agree with Lynn Langit's comment about installation and SilverLight dependency and the general comments about the UI. There are also a lot of smaller companies that don't run SQL Enterprise Edition but whom could benefit from MDS.
Those are the reasons why we are now developing a modern web application which we will host for our customers (probably on Azure).
If you're thinking about MDS I'd recommend to have a look at the API to replace (parts) of the UI.
Master Data Service is very useful for managing Master Data,
We have used Master Data Services 2012 and 2016, there are not too many features present in 2012 ,2016 is much better than 2012 with some new features , but I think still Microsoft needs to improve Master Data Services, they should include some flexibility in business rule's area.
Using VB.NET 2008
I want to know what is 3 Tier Architecture for windows application?
Can any one give a example of How to make a code for Inserting, Deleting, Updating in a database using 3 tier architecture.
Note am not asking a real code. Just give me a example.
From Multitier architecture
Three-tier'[2] is a client-server
architecture in which the user
interface, functional process logic
("business rules"), computer data
storage and data access are developed
and maintained as independent modules,
most often on separate platforms.
These days, a normal 3 tier application consists of a user interface written in Javascript, CSS and HTML which runs in the browser, a business rules layer which runs in a web server, and could indeed be built in VB.NET, and a storage layer which runs on a database server written in SQL and stored procedures.
Now it would be possible to do a user interface layer in VB.NET as a Windows application which then calls the business rules layer on the web server using a web services interface. This would give you more flexibility than the browser, and would not require learning as many APIs, however it is not common. It can really only be done in an enterprise situation.
This article has a simple VB.NET application that is a Windows GUI app, which call Google's web services API to do searches and to check spelling. That is a good example of a user interface layer. Then check this article for and exmple of a web service developed in VB.NET. This corresponds to the business rules layer, and in a real 3-tier application, it would be based around a database such as SQL server. If you were to use Access then it would not be a real 3-tier application. The database needs to be run on its own server and accessed across the network in order to be considered a tier.
The advantage of a 3-tier application is that you can scale each layer separately, and because each layer is simpler, scaling is also simpler. The DBAs can scale up to a database cluster, the business rules layer can scale up with a load-balancer and multiple servers, and the user-interface just gets replicated across as many clients as you need.
I don't know if is it the right way to use it, but I often use 3-tier int the following way:
One big Solution, with the name of the project
One dll project wich has the conection with the DB, using LINQ or whathever. Validating only the required fields of the DB
Another DLL project, wich has a reference to the project that conects to DB, and validate all data using the bussiness rules. Sometimes you may want a repositorium class wich has methods that can be used from the GUI layer
Finally, the GUI layer that can be HTML or WINForms, wich references to the bussines layer and calls all the appropiates methods, passing the data transparently and waiting for validation on the bussines rules.
You can comunicate with each layer using bool methods that returns true if everything is good, and personalized exceptions for each of the possible errors, and catch them on the upper layer.
I'll give you the gist of it. Real crash course.
You have three tiers:
DAL - Data Access Layer
BRL - Business Rule Layer
Presentation - The Forms, and such.
In the DAL, you configure how your application connects to databases, how it recieves datasets, etc. etc. Everything that has to do with data access.
In the BRL, you lay down how your program is going to handle the data it recieves from the DAL. Methods, and other things go in here.
And in the Presentation area, you simply make things purty and instantiate things from the BRL. The presentation area never has to touch the DAL, and that's the beauty of the 3tier layout. You can work on different areas and not step on other peoples toes.
I find the best way to understand it is to look at an example. If you go here:
http://www.codeproject.com/KB/vb/N-Tier_Application_VB.aspx
You can download an example and read the walk through for creating a very basic 3 Tier App in VB.Net. It's a little old in that it's a Visual Studio 2003 project but it should be easy enough to follow the upgrade wizard and get it up and running to check it out.
I'd like to give a brief overview about this style of programming and maybe I'll explain it in more details next time.
First of all, the 3-Tire concept engages dividing your program or application you are designing into 3 layers, the first layer is for manipulating the database in the operation called CRUD which stands for {Create,Read,Update,Delete} data from your database, using any kind of Databases : for example Oracle,SQLserver,MySql etc. That means you can connect your application with any type of databases without specifying a connection String to Only one database and we'll get more details about this next time.
The Second layer is Business layer which includes user data verification and other similar operations in which you process your business rules and the core of program,
The Third and Last layer is the Presentation layer which relates to User input and UI User Interfaces {The different forms for Input}
Frankly you can divide your Solution {Program,Application,Website} to sub-Programs to avoid data loss,organize your work, and to divide the development of your application among a team members.
in my point of view this is a great thing should be learnt in development, and as I was told by the grapeVine, if you want to enrich your knowledge and experience then you should be acknowledged about this important subject.
Our core business application uses a library (C# project) of business objects. Data access is done using the Wilson O/R Mapper (we're migrating to NHibernate this summer). The application has 3 front-end UIs: Windows Forms, ASP.NET, and a Windows Forms app that is installed on tablet PCs. The three front-ends perform different functions but they all access a core subset of the business classes.
The tablet PC application is the problem. We try to limit the amount of data pushed to the tablets to reduce the time it takes them to sync using SQL Server merge replication. The problem we've run into is when we add new functionality to the main application that we have no need to distribute to the tablet PCs or, if it's sensitive data, a strong need to not distribute it. Some of this can be controlled through replication, but we occasionally introduce dependencies in the core business objects that must be present in order for the O/R mapper to work.
Ideally, we would have two versions of the core business object library, Full and Compact. This seems like it would be a maintenance nightmare. Are there any strategies for managing this? Or alternatives? How does Microsoft manage the full and compact .NET Frameworks?
Your question talks about Tablet PC, which is really just XP and therefore the CF really isn't relevant, but for the sake of the question subject itself we can still talk about maintaining code used by the CF and the FFx (assuming you actually meant Windows Mobile or Windows CE).
First thing to know is that CF assemblies are retargetable. This means that a CF assembly can be directly used by a full-framework app without any recompiling (assuming it doesn't use any device specific stuff like P/Invoking coredll witout checking the runtime environment, using the WindowsMobile namespace, etc).
If using retargeting doesn't get you all the way there, then you can deal with the maintennace using compiler directives as well as partial classes. Daniel Moth covers tips on these quite well in his MSDN article.
One thing you may be able to do is if you can compile for each platform seperately you may be able to use compiler directives to limit what is needed by the Tablet PC platform. However with you using an OR mapper that may prove to be difficult.
Now in an ideal world you would actually have your Domain objects (the ones that map to the OR) with very very little business logic shared. Then have a BO layer that consumes these Domain objects. If you managed to break out your code base this way you could in theory then have just seperate layers you need to deploy depending on your need.
However it sounds to me more like you need to perform an intelligent split.
What you probably need to do is segment your code such that the Tablet PC BO are in the core root BO asseymbly. Then have a BO extension assembly that has the additional objects, rules, etc that are needed for the Winform / Web app versions.
So while you would have two domain level business object components at this point you would not actually have any duplication. As your Tablet PC BO object would also be the base for the Winform / Asp.net app. Then the extension dll would only contain the extras needed for the bigger versions of hte applications.
If you followed this approach it might make things easier to manage. Just look at it from the Common stuff needed everywhere and the specialized approach. :)
I can go into much greater detail if you want, just wanted to give you a basic hit.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Okay, I will shortly be starting down the path of windows mobile development. I know nothing about the subject really and I am looking for people with experience to let me know of any gottchas you may know of.
Right now I dont even have a breif of what is requied but the assumption is that the application will be very little more than a bunch of CRUD forms for updating data. The only other requirment knowladge I have is that the application will need to support offline storage when there is no signal avaliable. This in turn will obviously require some kind of syncronization when signal returns.
My initial thoughts are that the application will primarily be a front end to interact with a web service layer. Im assuming that WCF will be an appropriate technology for building these services? I also thought that SQL Server CE would be a good route to go down with regards to the offline storage issues.
Any knowlage that you feel is useful within this domain would be appreciated. Advice, links, books anything appreciated.
EDIT: It has been noted that there are two ways to go with off-line synchronization. To either use some form of message queuing or to use SQL synchronization tools. Could anyone offer a good comparison and introduction to these?
EDIT 2: After a little more digging I get the impression that there are basically 3 different approaches I can use here:
Emmbeded Database to query against then syncronization online, when able
MSMQ along with .NET remoting
WCF with ExchangeWebServiceMailTransport bindings using Exchange Server.
Now, there has been a nice few points raised on the first issue, and I think I understand at some level the issues I would face. But I'd like to get a little more information regarding MSMQ implementations and using WCFs new bindings.
Here a few words from my experience so far (about 9 months) of .net Windows Mobile development.
Well you are occasionally connected. (Or more likely occasionally disconnected). You have to choose whether you are going to use messaging with queues (i.e. WCF/SOAP/XML or something like it) or database synchronisation. I choose the SQL synchronisation route so I can't really comment on messaging. The SQL synchronisation route is not hassle free!
If you go down the sync route with SQL compact like me you basically have two choices. SQL Server merge replication or the newer ADO.NET Synchronisation services. If you choose the former you need to be really careful with your DB design to ensure it can be easily partitioned between mobile subscribers and the publisher. You really need to think about conflicts, and splitting tables that wouldn't normally be split in a normalised DB design is one way of doing that. You have to consider situations where a device goes offline for some time and the publisher DB (i.e. main DB) and/or a subscriber alters the same data. What happens when the device comes back online? It might mean resolving conflicts even if you have partitioned things well. This is where I got burnt. But SQL Merge Replication can work well and reduces the amount of code you have to write.
Roll your own DAL. Don't attempt to use datareaders etc. directly from UI code and don't use typed datasets either. There may be third party DALs that work with Windows Mobile (i.e. I know LLBLGEN does, might be worth a look) but Linq-to-SQL is not supported and anyway you need something lightweight. The chances are the DAL won't be too big so roll it yourself.
If you are using .net you'll probably end up wanting some unimplemented platform features. I recommend using this inexpensive framework to give you what your missing (especially as related to connectivity and power management) - http://www.opennetcf.com/Products/SmartDeviceFramework/tabid/65/Default.aspx
Windows Mobile devices partially switch off to save power when not in use. If you are doing a polling type design you'll need to wake them up every x mins. A normal .net timer class won't do this. You'll need to use a platform feature which can be used from OpenNetCF (above). The timer class is called LargeIntervalTimer and is in the OpenNetCF.WindowsCE assembly/namespace (I think).
Good Luck!
SqlCE is only one of the options available for local data storage on a Windows Mobile device, and although it's an excellent database it has limitations. For one thing, SqlCE will not work (period) under encryption (in other words, if your user encrypts the location where your SDF file is, you will no longer be able to access the data).
The second (and most critical) weakness of SqlCE lies in the RDA/Merge Replication tools. SqlCE Merge Replication is not 100% reliable in situations where the network connection can drop during replication (obviously very common in Windows Mobile devices). If you enjoy trying to explain missing or corrupted data to your clients, go ahead and use SqlCE and merge replication.
Oracle Lite is a good alternative to SqlCE, although it too doesn't work properly under encryption. If encryption is a potential problem, you need to find a database engine that works under encryption (I don't know of one) or else write your own persistence component using XML or something.
Writing a WM application as a front end that primarily interacts with a web service in real time will only work in an always-connected environment. A better approach is to write your application as a front end that primarily interacts with local data (SqlCE, Oracle Lite, XML or whatever), and then create a separate Synchronization component that handles pushing and pulling data.
Again, SqlCE merge replication does this pushing and pulling beautifully and elegantly - it just doesn't work all the time. If you want a replication mechanism that works reliably, you'll have to write your own. Oracle Lite has something called a snapshot table that works very well for this purpose. A snapshot table in Olite tracks changes (like adds, updates and deletes) and allows you to query the changes separately and update the central database (through a web service) to match.
This thread I just posted on SO a few days ago has proven to be a great resource for me thus far.
Also the Windows Mobile MSDN WebCasts are a wealth of information on everything from just getting started up to advanced development.
I would suggest Sqlite for local storage. From the last benchmark I ran it was much better than SqlCe and you don't have to do stupid things like retain an open connection for performance improvements.
Trade-offs being that the toolset is less rich and the integration with other MSSql products is nil. :(
you might want to refer to this:
getting-started-with-windows-mobile-development
You shouldn't be intimidated for windows mobile development. It isn't much different from desktop development. I strongly recommend that you use .NET Compact Framework for development and not C++/MFC.
Some useful links:
Mobile section at the Code
Project. You would find a lot of
articles, a little digging is needed
to find the appropriate one.
Smart
Device Framework from OpenNetCF
offer valuable extensions to the
compact framework.
When you install
the Mobile SDK, you will find under the
Community folder links for the
Windows Mobile and CF framework
blogs. These are also valuable
resources.
Regarding your application, you are right about the WCF and the SQL Server CE. These are the proper ways for handling communication and storage.
Some hints for people coming from a desktop world:
You need to have some sort of power management. The device may automatically go to suspend state. Also, you shouldn't consume power when you don't have to.
Network connectivity is a difficult issue. You can register notifications for when a specific network (Wi-Fi, GPRS) becomes available or unavailable. You can also set the preferred means of communication.
Make the UI as simple as possible. The user uses his thumb and/or a pen and he is probably on the move.
Test in a real device as early as possible.
"24 Hours of Windows Mobile Application Development" from the Windows Mobile Team Blog has some good resources
If you can, try to start from the user use cases and work back to the code, rather than vice versa. It's really easy to spend a lot more time working on the tools than working on the business problem. And thinking through user requirements will help you consider alternate strategies, because a lot of the patterns you know from normal .NET don't apply.
I've done lots of intermittent application development of exactly the type you are describing, and an on-board database works just fine. The MSMQ/WCF stuff just adds conceptual overhead without adding much value. You need a logical datastore locally anyway, and replication at this level is a simple concept that you want to keep simple, so the audit trail is easily monitored and debugged. MSMQ and WCF tend to hide things in unfamiliar places.
I upvoted the SqlLite suggestion BTW. MS doesn't have their persistence story stabilized yet for CE.
For the database replication bit I highly recommend Sybase Ultralite. In terms of flexibility and performance it knocks the socks off SQL CE
I had to do this once. Weird setup with Macs for development, and we were all Java programmers. And a short deadline. PowerPC macs too, so no chance to install Windows for Visual Studio development, never mind that the money for this would never have appeared.
We ended up writing applications using Java, running on the IBM J9 virtual machine, with SWT for a user interface. Entirely free development stack. Easy to deploy. Code ran on any platform we desired, not just PocketPC/WinMob.
Most of the work was on the server side anyway - the database, the web service server. The logic. The reporting engine. The client side wasn't totally simple however - would get the form templates from the server (because they changed frequently), the site details (multi-site deployment), generate a UI from the form template (using some SWT GUI components that are wonderful for PocketPC development, like the ExpandBar), gather data with a point and click interface (minimising keyboard entry where possible), and then submit it back to the server.
For offline storage we used XML files on the device itself. More than enough for our needs, but yours may differ. Maybe consider SQLite?
There are a couple links you can check out to start with:
http://developer.windowsmobile.com
http://msdn.microsoft.com/en-us/windowsmobile/default.aspx
If you have a sticking point while developing, there are also Windows Mobile dedicated chats on MSDN that you can attend and ask your questions. The calendar hasn't been updated yet, but the next ones should be in January. You can find the schedule here: http://msdn.microsoft.com/en-us/chats/default.aspx
I am going to add an additional question to this post, as its been active enough and hopefully will be helpful to others as well as me. Ok, so after playing around I now realize that standard class libraries cannot be included in windows mobile applications.
Now the overwhelming advice here seems to be use an embedded database, though I now do have use cases and it appears that I will need to have document synchronization as well as relational data. With this in mind service layer interaction seems inevitable. So my question is how would I share common domain objects and interfaces between the layers?
"Document synchronization" - does that mean bidirectional? Or cumulative write-only? I can think of mobile architectures that would mainly collect and submit transactions for a shared document - if that's your requirement, then we should discuss offline - it's a long (and interesting) conversation.
Owen you can share code from Compact Framework -> Desktop, it's only Desktop -> Compact Framework that has compatability issues if you use certain objects that are not supported by the CF.
While a desktop lib doesn't work on CF a CF lib WILL work on the desktop, you can also run CF.exes on the desktop!
Just create a CF library as the project that defines your base objects / interfaces etc.
This book sshould e essential reading for all Windows Mobile developers: http://www.microsoft.com/learning/en/us/books/10294.aspx
For developing windows mobile applications you must have the basic tools like silverlight, visual studio, windows phone emulator and sqlite as your database storage.